4 ms·
> Linux doesn't help this by overcommitting memory that it doesn't actually have. As long as the POSIX fork/exec pattern is implemented with a CoW address spac
by mappu 6y ago
> Linux doesn't help this by overcommitting memory that it doesn't actually have.
As long as the POSIX fork/exec pattern is implemented with a CoW address space, you can just write all over memory to cause new physical allocations. There's no malloc ENOMEM return to check in this case.
(You can do this on Windows too via RtlCloneUserProcess and friends.)
You could "solve" this problem by implementing fork/exec to use copying instead of CoW (like Cygwin and PDP-11 Unix), but I don't think anyone wants that, especially because you'd usually throw away the work with exec() anyway.
- wtallis 6y agoI think he's suggesting that the fork itself should fail if the subsequent overwrite pass to defeat CoW would cause problems. So you would have trouble actually directly using all of your RAM if you had some processes that don't follow a fork with an exec—but that leftover physical RAM should still be able to be used for the disk cache.
- duskwuff 6y ago> I think he's suggesting that the fork itself should fail if the subsequent overwrite pass to defeat CoW would cause problems. That'd put you in the unusual position of forbidding any sufficiently large process from ever creating children. The kernel has no way of knowing whether a fork() will be followed by exec().
- hyperman1 6y agoIf posix_spawn is a syscall, it would be a decent replacement.