Conversation

Jun 26, 2021

💯 > In general, it is my opinion that if your program is crashing on Alpine, it is because your program is dependent on behavior that is not guaranteed to actually exist, which means your program is not actually portable

Quote Tweet

Ariadne Conill

@ariadneconill

Jun 25, 2021

understanding thread stack sizes and how alpine is different ariadne.space/2021/06/25/und

Replying to

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

Replying to

and

Wait, isn't that committed on demand? It doesn't actually eat 8 MiB of physical RAM per thread, does it?

Replying to

and

it depends on whether or not vm.overcommit_memory=0 or vm.overcommit_memory=2.

Replying to

and

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...

Replying to

and

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.

Replying to

and

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?

Replying to

and

i mean, sure, if you live in overcommit-world it's not a huge part of it (but VSZ stats are still troubling), but disabling overcommit is quite common in alpine world.

Replying to

and

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...

Replying to

and

do you run a lot of electron/chromium stuff? it intentionally wastes a lot of ram in order to lay things out so its hard to JIT spray

Replying to

and

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.

4:36 AM · Jun 26, 2021Twitter Web App

Replying to

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.

Julia REPL stan account

Replying to

Is there a similar firefox option? Sorry for the q, noob here.

Replying to

It has multiple options for disabling various tiers of the JIT but I'm not sure if they have a way to fully prevent it from generating native code at runtime. You can at least mostly disable it in Firefox though.