also glibc sucks for defaulting to giving every thread 8MiB of stack. if you're wondering why alpine is more memory efficient, this is a HUGE part of it
Conversation
Wait, isn't that committed on demand? It doesn't actually eat 8 MiB of physical RAM per thread, does it?
3
1
3
if overcommit is disabled (=2), it will take all of it at once, and malloc will be allowed to fail (return NULL), and you won't have to deal with the OOM killer. this is really the better way to run...
2
3
but, running without overcommit DOES mean that all of an allocation has to be fulfilled when its requested. and of course, non-Linux systems don't really have that magic overcommit stuff.
1
2
Of course, this is a whole different debate. But overcommit should be enabled on most typical Linux systems, which means 8MiB aren't actually consumed per thread, so then Alpine shouldn't actually be more memory-efficient due to that, no?
2
1
Fair. The reason why I ask is that I find the amount of RAM used by stuff on my main workstation to be quite ludicrous these days. 32GB and I still regularly get close to running out (no swap, though).
I thought it might be an i915 leak, but now I'm on radeon, no change...
1
1
You can run Chromium with --jitless to save a ton of memory and substantially improve security at the expense of performance. Can also enable other options to save a lot of memory. It scales the memory usage based on available system memory quite a lot. Can adjust that though.
2
1
2
If you don't use any particularly heavyweight web apps depending on stuff like wasm, --jitless impact on performance isn't really that noticeable. It's around 5-10% perf loss for a normal JS-heavy web page like Gmail or YouTube. Compute-heavy code could be 10-100x slower though.