Performance issue with chromium and evolution

papercut

The issue is that when launching Chromium or Evolution it can take upwards of 2 to 4 minutes to load up. Every other X application loads in seconds. I'm using Gnome, but I've been able to duplicate the same issue in Mate and plain X. Snappy X, snappy apps, except these 2. All the base package Gnome apps load in a few seconds.

Chromium afterwards doesn't seem to have any problems with rendering webpages or loading new tabs. Whether kept in memory or restarted. With Evolution, I found the program hanging today for the first time with tearing in the window display. I couldn't really do much with it but wait for a few minutes.

Specs: Ryzen 5, WX 2100 (Polaris GPU), 32 GB RAM. DMESG and X.log.0 shows that the Polaris GPU are detected. Its not running on llvmpipe.

I have an older GPU Intel laptop with similar desktop setup and its much faster which it shouldn't be unless the video driver?

I haven't touched SMT settings or softupdates atm. Is this possibly a video card issue, tweaking issue, or should I just try different apps? I can't see much to tweak in man amdgpu.

rvp

papercut Is DBus being started in /etc/rc.conf.local?

$ fgrep messagebus /etc/rc.conf.local 
pkg_scripts=messagebus
$

You might also need something like this in ~/.xinitrc (or ~/.xsession):

export XDG_RUNTIME_DIR=/tmp/runtime-${LOGNAME}
test -d $XDG_RUNTIME_DIR || install -d -m 700 -o $(id -u) -g $(id -g) $XDG_RUNTIME_DIR
test -d $HOME/.local     || install -d -m 700 -o $(id -u) -g $(id -g) $HOME/.local

if [ -x /usr/local/bin/dbus-launch -a -z "${DBUS_SESSION_BUS_ADDRESS}" ]
then eval "$(dbus-launch --sh-syntax --exit-with-session)"
fi

Not sure what else needs to be running. When you installed the package, it would've told you all the stuff it needed for proper operation.

papercut

Thanks for replying. I was mulling this over for a few weeks before posting.
Two things (below) seemed to have improved the performance considerably to the point I'd consider it useable.

Yep, have Dbus running. The /usr/local/share/doc/pkg-readmes is handy and I've been following those. I've implemented the .xinitrc suggestion.

Hopefully the following might help others with amdgpu problems. I rebooted between each change and was able to see a difference.

The first thing I tried was update to Current.
There is a commit saying "Reimplemented the page allocation code using bus_dma(9) .... This fixed amdgpu(4) and radeondrm(4) ....."
I don't know if this patch relates to the problem I was having, but Video seems faster, less sluggish now. Current also updated the AMDGPU firmware. I had run fw_update on 7.1.

Second thing changed/updated was sysctl.conf
I noticed an error in Xorg.0.log mentioned
checkDevMem: failed to open /dev/xf86 and /dev/mem (Operation not permitted) Check that you have setmachdep.allowaperture=1in sysctl.conf.
Since setting that and rebooting, video and load time performance increased again.

bsduck

papercut macdep.allowaperture=1

Rather machdep.allowaperture, otherwise people will think they have to allow installation of https://en.wikipedia.org/wiki/Aperture_(software) on their Mac :)

rvp

papercut Re: the machdep.allowaperture knob: I've seen that message myself, but, I don't think setting the knob has any effect because:

On OpenBSD (mine is 6.9), like on Linux, the Xorg binary is not setuid root (as the default modesetting driver doesn't need it)

$  ls -l /usr/X11R6/bin/Xorg 
-rwxr-xr-x  1 root  bin  2982720 Dec 11  2021 /usr/X11R6/bin/Xorg
$

therefore, the X server can't open those 2 devices because of their permissions:

$ ls -l /dev/xf86 /dev/mem
crw-r-----  1 root  kmem     2,   0 Oct  5  2021 /dev/mem
crw-------  1 root  wheel    2,   4 Oct  5  2021 /dev/xf86
$

Check your Xorg.log; it should still be complaining ;)

papercut

bsduck

Right. haha I typed it in manually. Its correct on my system of course.

I edited my post.

papercut

Thanks for the feedback. I think I've narrowed down the problem to either HDD IO or perhaps CPU (idle/sleep). If I run top, before loading a couple of problems, I see the process being started stays in a sleep/idle state. Most of the CPUs stay idle as well. I don't know enough about SMP performance with OpenBSD to comment further. I just know, that the HDD IO compared to SSD on this system is considerably slower. I don't know if I have enough to file bug report other than speculation. I'm going to continue using Open on this system, and I'll see if these issues get ironed out. If it continues to annoy me, I suppose I could just use an SSD.

I have a spare SSD but its too small and old that I don't want to run an OS on. Let me just say, all the problems I had with load times, etc are gone with using the SSD.

The HDD I am using for Open has run IO intensive things quite well on another OS. The laptop I'm running Open on is also using an HDD with Gnome and it doen't have the same speed issues. It leaves me wondering if there isn't an IO problem with the chipset (edit: driver in OpenBSD). Another user on the mailing list recently trying to load Chromium with an AMD A8 w/ 8 GB complained of slow HDD IO and said it was also fixed using an SSD. The HDD IO, shouldn't be this bad.

Some in Open mailing list said amdgpu was slower on 7.x then 6.9. So after trying 7.1 and -Current (as of this weekend). Then I fresh installed 6.9. With 6.9, I removed gdm + gnome, disabled messagebus, gdm and used xdm + xfce. Somethings do load faster, but not as fast as would be expected on an HDD. The same setup on SSD gives the 'normal' expected HDD speed. My laptop with HDD is also running 7.x with Gnome on Intel graphics no speed issues there.

I've thought the blame was on amdgpu but I think it seems actually more with HDD IO (chipset? driver in OpenBSD* ) or maybe CPU state (idle/sleep) . I've tried tweaking londer.conf, sysctl.conf and such to no avail.
*edit: I write this because I dual-boot this system, and the other OS uses an HDD and SDD and no disk IO problems. In fact, I've also tried FreeBSD and some Linux distros, also no problems even with the same HDD.

rvp

papercut

Are running apmd? That can throttle the CPU frequency.
This could just be the browser "phoning home" to check for updates and such...

papercut

Nope no apmd. I consider this issue closed now. For me anyways!

I put a new SSD on the system and it fixes all the slowdown.