Performance regressions on 6.11

The issue is that certain operations are much slower on kernel 6.11, since the start of the merge window. 6.10 exhibits none of these issues.

Most commonly, simply repeatedly switching focus (and therefore, cursor) between different monitors on sway is enough to cause clients on either monitor to drop 8 frames or so. libwayland itself warns that the system is too slow.

perf top shows that delay_halt() has higher activity than before 6.11 while repeatedly switching focus.

New windows also open slower, and some games have new large lag spikes.

The best setup to replicate would be to use sway, use two monitors, run mpv on both with a 60fps (or higher) framerate video, and switch focus back and forth quickly.

My guess is that certain uploads or downloads block for longer, causing clients to lag behind.

changed the description

I had a similar issue with lag spikes between different monitors that I bisected to 0ddd2ae586d28e521d37393364d989ce118802e0 (drm/ttm: increase ttm pre-fault value to PMD size). Reverting this commit on 6.11-rc4 fixed it.

I went back to 6.11-rc3 to get a (incomplete) function_graph trace of ttm_bo_vm_fault_reserved which I have attached as trace.xz. TL;DR: vmf_insert_pfn_prot is a bottleneck.

Reverting 0ddd2ae586d28e521d37393364d989ce118802e0 didn't improve anything on my system.

@ckoenig Any ideas?

mentioned in issue #3564 (closed)

mentioned in issue #3573

drm-fixes-2024-08-24 being merged did make the situation a little better, but its still dropping quite a lot of frames by just changing a cursor texture. 6.10 in contrast doesn't drop any frames.

Reverting any commits mentioned previously did nothing. Additionally, I can replicate the effects of #3519 only in 6.11, though it may be unrelated.

Experiencing severe performance issues on 6.11-rc5, running the Wayfire compositor. It never ran this poorly when screen capturing before. OBS Studio now eats almost a whole core just capturing one desktop.

I have similar issues on plasma 6 with 7900xtx. Issues started with 6.11-rc1. There is significant lag and performance drop when I'm simply moving cursor between screens. I have bisected this issue to 38e0c3df6dbd36e69d38f67853cdd1bb6110d05f. Tried to revert it but it results in some conflicts I don't know how to fix.

Thanks for bisecting, can confirm 38e0c3df6dbd36e69d38f67853cdd1bb6110d05f caused the issue. Reverting it fixes it. Conflict is trivial to fix, just delete dm_plane_layer_index_cmp.

@leoli Could you look into this?

I'm testing the revert as well, thanks for confirming this. Not that my voice adds much weight, but it's nice to see the issue pinpointed.

@lynne thanks for bisecting this, I'm trying to reproduce this currently. In the meantime, are you able to see if commenting out these lines help? https://github.com/torvalds/linux/commit/38e0c3df6dbd36e69d38f67853cdd1bb6110d05f#diff-712b36e3b221fabc394675ee3e625da7861c2ff8a07e05315c18743ebca7f6efR10538-R10540

Can confirm, commenting out those 2 lines eliminates the issue.

Does this mean the original revert can now be replaced by simply removing that one condition/return statement?

Commenting those two lines out was a quick hack to check my suspicions. We wouldn't want to merge that since it'll likely prevent z-pos changes for kms planes from taking effect.

That said, I'm having some trouble reproducing this. What I did find was that Sway 1.10 seems to have a performance improvement over 1.9 on my Ryzen 7520u system. Though it may not be related to the change in question, since whether it's reverted or not has no observable impact for me.

@lynne What does your system setup like? On my end:

• Ryzen 7520u w/ integrated gfx
• 1920x1200 165hz embedded panel + 4k60 external DP
• Kernel built on amd-staging-drm-next (I also tried Linus's v6.11-rc6 tag)
• Sway built on v1.10 branch

I'm playing this video via firefox on the external DP to detect stutters while moving the cursor between the two displays.

I'm on a 7900XTX, using sway and wlroots git master, with WLR_RENDERER=vulkan. Testing with a 60fps video in mpv, using the gpu-next renderer. Screens are a 1080p75 (rotated 90 degrees) and a 4k 144hz.

I've tried drm-next too, and it doesn't fix the issue.

I can also confirm that commenting out those lines fixes the issue. To add more context, I'm on plasma 6.1.4, 7900XTX and two screens: 4k@60 on DP and 4k@120 connected through DP->HDMI 2.1 adapter, both with HDR enabled. With this setup I don't have to play any video to experience this issue, just moving mouse cursor between screens is enough. Maybe it have something to do with bandwidth required for 4k@144 and 4k@120 screens?

edit: don't look like it, I have switched resolution to 1080p on second screen and it's still the same

I got my hands on a W7900 (which should practically be the same as a 7900xtx) to align my setup as much as possible. No luck reproducing yet, maybe I'm chasing the wrong thing? Here's a video of what I'm doing: https://youtu.be/yj-b3sgdEy8?si=T8CUtNNeXgC705V3

In any case, I have a suspicion of what's going on. @lynne, @Witek, will you give this patch a try to see if it helps? 0001-drm-amd-display-Do-not-reset-planes-based-on-crtc-zp.patch

I think kwin might be using a software cursor, which is why you can't replicate.

I'll test the patch tomorrow once the drm-fixes for 6.11-rc7 are in.

Yes, I read elsewhere that kwin added an override to use software cursors on AMD, to dodge a kernel bug. It may or may not have been the VRR on atomic modesetting issue, which should be improved in kernel 6.11.

I can confirm that the patch works. Looking through your video, the setup you have tested on is very similar to mine. I have captured what it looks like on my side, so you will know what you are dealing with: https://youtu.be/54qRIE8RBg4 Maybe you will find something in this video.

Tested the patch, it does indeed fix the issue.

Thanks for the feedback all, I'll send this out for review. Cheers!

added DC label

added bisected label

Fix submitted here: https://lore.kernel.org/amd-gfx/20240906212021.74460-1-sunpeng.li@amd.com/

closed

mentioned in commit agd5f/linux@578aab4e

mentioned in issue #3465

mentioned in commit agd5f/linux@c5b1a066