Due to an influx of spam, we have had to temporarily disable account registrations. Please write an email to accountsupport@archlinux.org, with your desired username, if you want to get access. Sorry for the inconvenience.
There's a sudden increase in RAM usage with kernel 6.7, which sounds like a bug to me. Below is the output of the free -h command when starting my Xfce session with the linux 6.7.arch3-1 and linux-lts 6.6.12-1 kernels (which I'm now using because of this problem):
# linux 6.7.arch3-1 total used free shared buff/cache availableMem: 3,4Gi 1,1Gi 2,1Gi 3,0Mi 541Mi 2,4Gi# linux-lts 6.6.12-1 total used free shared buff/cache availableMem: 3,4Gi 762Mi 2,4Gi 3,1Mi 503Mi 2,7Gi
The difference is "only" 300Mi at startup, but then it gets worse over the course of the session, probably reaching 500-600Mi (at least), so that a small machine like this, still usable with the lts kernel and Xfce, starts to become really unusable with the non-lts kernel (basically, it's no longer possible to open even slightly imposing software like Thunderbird in addition to Firefox without exceeding 90% RAM usage).
Additional info:
package version(s): 6.7.arch3-1
config and/or log files:
link to upstream bug report, if any:
Steps to reproduce:
Upgrade from linux 6.6.10.arch1-1 to 6.7.arch3-1 (or switch between linux and linux-lts) and compare RAM usage
Maybe.. but there's no firm indication of an Arch packaging bug i.e. you would need to report it upstream to the kernel folks (see below). But one possibility which seems a bit suss in the Arch config between 6.6 and 6.7 is the enabling of ZRAM_MEMORY_TRACKING. A recompile with that option turned off is an easy test. Anyway, please let us know what you find out.
FWIW, I can replicate your test results. Although, for testing I typically run 2GB VM's and they are still as smooth as butter.. even with tons of apps loaded. BTW, not sure if free is the best way to measure memory usage on Linux.. which is often misunderstood. There always seems to be threads about memory usage in the forum. The latest one is here.
But one possibility which seems a bit suss in the Arch config between 6.6 and 6.7 is the enabling of ZRAM_MEMORY_TRACKING. A recompile with that option turned off is an easy test. Anyway, please let us know what you find out.
So, since I had started this test, I let it finish, even though the tests already done in the forum thread seemed to make it obsolete. After 36 hours of compilation (!), I was finally able to test the resulting kernel, and I confirm that it doesn't change anything. Needless to say, I won't be able to do any more tests of this nature on my own, i.e. when it comes to building the kernel.
I have also tested the kernels proposed in https://bbs.archlinux.org/viewtopic.php?pid=2145699#p2145699, and confirm that the first kernel (with the offending commit reverted) fixes the problem, while the second (with the patch supposed to fix the problem, I believe) does not.
I'd also like to point out that using kernel option transparent_hugepage=never seems to cancel the effect of the offending commit, i.e. I get essentially the same memory usage at session startup whatever the kernel version tested if this option is enabled (from linux-lts 6.6.13-1 to linux 6.7.arch3-1 through the various intermediate builds):
total used free shared buff/cache availableMem: 3.4Gi 479Mi 2.5Gi 2.2Mi 510Mi 3.0Gi
NB1: Maybe free isn't the best way to measure memory usage, but since I started with it, I'll continue.
NB2: All this only concerns memory usage at startup, I suppose that in all rigor we should also check that memory usage then increases normally during the session.
Looking more closely at the offending commit message, and reading a bit of the transparent_hugepage doc, I understand better why setting this option to never solves the problem and I'd be tempted to believe that this isn't a bug but, so to speak, expected behavior, or at any rate an expected side effect considered acceptable.
So I'm not going to launch into an upstream bug report, which sounds complicated and impractical, only to be told that it's a feature. I'll leave you to close this issue in case you'd like to keep it open instead.
Why not, memory usage at startup seems to be closer to what it was before:
total used free shared buff/cache availableMem: 3,4Gi 673Mi 2,5Gi 2,2Mi 509Mi 2,8Gi
I'm going to test it a bit over time to see if it stays correct during a session. In any case, I've been testing all day with transparent_hugepage=never and the gain in terms of memory usage over time is very significant without any noticeable impact on performance for me, so I might go back to this setting in the end because I find it's better than before.