5 ms·

I think the difference between "don't implement workarounds" and "use overcommit" is that the kernel can try to be clever, but userland should not have to be cl

I think the difference between "don't implement workarounds" and "use overcommit" is that the kernel can try to be clever, but userland should not have to be clever. The kernel is supposed to just make things work for userland. I think that's why overcommit exists. It's generally not easy to re-design all userland applications to deal with difficult memory management problems in a complex system, but it is easy to just lie to them all so they can continue to do stupid things and not crash. If you have a system with only "100% correctly written" software, just disable overcommit (echo 2 > /proc/sys/vm/overcommit_memory).

dooglius 7y ago
The problem is that userland has to be really clever because of overcommit... that's what the whole thread is about! The reason people want complex things like fsync and barriers is that the OOM killer has normalized the bad idea that applications should behave well when suddenly SIGKILL'd, and this is way harder than looking at the return value from malloc. When a program I write has elevated permissions, which fortunately is often, I will always write -1000 into my oom_score_adj, but not everyone has this luxury.
- zielmicha 7y ago
  You don't need fsync if you only care about your user process being killed. It protects only against power loss/kernel crash - the filesystem is not running as user process, so it can't be killed.
- deleted 7y ago
  [deleted]
- gpderetta 7y ago
  >bad idea that applications should behave well when suddenly SIGKILL'd, That's not a bad idea, that's the way that any application that cares about not losing data should behave. OOM is just one of the any reasons an application might suddenly die.