You are not logged in.
Same problem here on two PCs, both running Arch XFCE with AMD Radeon (xf86-video-ati) graphics drivers.
Kernel 6.7.1 still does not fixes the bug. Will it be fixed in 6.7.2 since the bad commit was already identified and (if I got it well) reverted upfront?
Offline
transparent_hugepage=never
https://wiki.archlinux.org/title/Kernel_parameters
Where did you spot that the bad commit was reverted? loqs' bisection kernels don't imply any upstream action, they're only for debugging.
Offline
Probably 6.7.2 won't change anything (there is 6.7.2-rc which doesn't mention anything about this issue).
There's another patch but it targets arm64 platform https://lore.kernel.org/all/20240124101 … ernel.org/
But it seems two issues discussed related to this patch do not include the issue mentioned in this thread here, and nobody reported it upstream yet. If nobody reports it, nobody will fix it either.
I don't run 6.7.x myself yet, I usually wait for it to reach .5+ since there's always weird issues early in a series...
Offline
I tested using transparent_hugepage=madvise and it also lowers the idle ram usage as well.
free -h
total used free shared buff/cache available
Mem: 1.7Gi 702Mi 719Mi 19Mi 600Mi 1.1Gi
Swap: 5.2Gi 0B 5.2Gi
This should be better because if an application wants to use hugepages it can and shouldn't result in a possible performance degradation that using =never could do.
Also I will say that there should be a demostrable way that the new kernel change actually improves performance because the only thing it changed on my PC was make dunst or polybar double their mem usage, and this will only hurt low memory computers for a theoretical gain on something else.
edit: Been testing with madvise for a while and feels smooth, no hangs when launching applications,etc which did happen when the idle ram usage was higher.
Last edited by Samueru (2024-01-24 22:15:04)
Offline
There should be a demostrable way that the new kernel change actually improves performance because the only thing it changed on my PC was make dunst or polybar double their mem usage, and this will only hurt low memory computers for a theoretical gain on something else.
I would the performance gain / loss to be dependent on workload and hardware. You could raise it with upstream. Any change in the kernel code needs to come from upstream anyway. Given https://gitlab.archlinux.org/archlinux/ … /issues/23 has been closed Arch is not going to make any change for the issue.
Offline
Samueru wrote:There should be a demostrable way that the new kernel change actually improves performance because the only thing it changed on my PC was make dunst or polybar double their mem usage, and this will only hurt low memory computers for a theoretical gain on something else.
I would the performance gain / loss to be dependent on workload and hardware. You could raise it with upstream. Any change in the kernel code needs to come from upstream anyway. Given https://gitlab.archlinux.org/archlinux/ … /issues/23 has been closed Arch is not going to make any change for the issue.
Oh I know it is not an issue with Arch, What I said above was after reading what Gael said of not bothering to raise the issue upstream because he will likely be told that it is a feature.
Thanks for all the help again building the kernels, will see if I end up raising the issue upstream myself.
Last edited by Samueru (2024-01-24 22:38:08)
Offline
Thanks for all the help again building the kernels, will see if I end up raising the issue upstream myself.
Perhaps you could add it to Improving_performance#RAM,_swap_and_OOM_handling
Offline
The issue was fixed by kernel 6.7.6!
Offline