Hi,I tried the workarounds: they work, however I had left the system with overcommit memory 0 (default), since it seemed to be resolved.
This morning, however, I detected a problem relating to memory (the first time I see an OOM-Killer recall process) following an extreme slowdown in the system; and I think it could be related to this problem.
lug 05 12:35:27 kernel: kswapd0 invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj> lug 05 12:35:27 kernel: Hardware name: Dell Inc. Precision T1600/06NWYK, BIOS A10 02/21/2012
lug 05 12:35:27 kernel: Mem-Info:lug 05 12:35:27 kernel: active_anon:2283373 inactive_anon:768638 isolated_anon:0 active_file:5800 inactive_file:5241 isolated_file:0
unevictable:39 dirty:52 writeback:0slab_reclaimable:17302 slab_unreclaimable:55651
mapped:10150 shmem:3002 pagetables:19384 sec_pagetables:0 bounce:0 kernel_misc_reclaimable:0 free:34007 free_pcp:109 free_cma:0lug 05 12:35:27 kernel: Node 0 active_anon:9133492kB inactive_anon:3074552kB active_file:23200kB inact> lug 05 12:35:27 kernel: DMA free:13312kB boost:0kB min:60kB low:72kB high:84kB reserved_highatomic:0KB>
lug 05 12:35:27 kernel: lowmem_reserve[]: 0 3133 15872 15872lug 05 12:35:27 kernel: DMA32 free:64276kB boost:0kB min:13328kB low:16660kB high:19992kB reserved_hig>
lug 05 12:35:27 kernel: lowmem_reserve[]: 0 0 12739 12739In my opinion, to avoid stability problems, I think it is preferable to perform the revert of the indicated commit, until all any repercussions are clarified (rather than configuring the desktops with overrtcommit memory 1).
What do you think? Il 04/07/23 00:06, Aurelien Jarno ha scritto:
Hi, On 2023-07-03 22:15, Aurelien Jarno wrote:It's not clear to me either what's the issue. So far I have just found that the virtual memory allocation of plasmashell is ~11GB with glibc 2.37 vs ~2GB with glibc 2.36. In both cases the resident memory is around 350MB. This higher virtual memory allocation seems to cause the clone syscall to fail with -ENOMEM.However, now the problem seems to have solved.Yes, it's great that you have found a workaround. Given that, I don't think it warrants blocking the migration of glibc 2.37 to testing, but I'll continue investigating to better understand if it could have other side effects.The issue is due to this upstream commit: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=f4f2ca1509288f6f780af50659693a89949e7e46 Other possible workarounds are: - defining the GLIBC_TUNABLES environment variable to "glibc.malloc.trim_threshold=128" - changing the kernelvm.overcommit_memory parameter to 1 with "sysctl vm.overcommit_memory=1" Regards Aurelien