Re:In defence of swap: common misconceptions
by wtallis on Tuesday June 09, 2020 @03:17AM
(#23464472)
I 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.
Re:In defence of swap: common misconceptions
by duskwuff on Tuesday June 09, 2020 @03:53AM
(#23464657)
> 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().
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.