Conversation

Replying to
so I went digging on my desktop session.. pretty much anything written in Go or anything with a JS engine attached to it (firefox, chromium, node) have like 10-100x VIRT compared to what's actually in use. was considering disabling overcommit to try... doesn't look fun x.x
List of processes. There are 11 Firefox processes, one of which is highlighted. The highlighted process has 27.5G of virtual memory but only 231M resident + 105M shared.

A similar pattern is exhibited among other processes, with about 3G of virtual and only <1G of resident + shared.
1
Replying to
I've kind of thrown my hands up and accepted overcommit + uspace oomd; I test with WebKit too for my job which allocates 80-90G virt. Is there a benefit to going without overcommit? I'm not a kernel hacker by any means, so I just kind of accept the knob and move on. /shrug
1
Replying to
Ah - I've been using systemd-oomd (Fedora 34 defaults) - it triggers on PSI and targets the app causing the stalls (IIRC also avoids targeting shell) - I can successfully report no more shell/X kills and no freezes for months! Overengineered? probably. Seems to work though. 😅
1
Replying to
got it - I've just seen enough "clever" use of overcommit - for example, mmap'ing 32G of PROT_NONE memory between heaps to avoid heap overruns from succeeding in JSCore - phakeobj.netlify.app/posts/gigacage/, or using CoW+fork to save in Redis - redis.io/topics/faq#bac that...
3