Messages in this thread | | | Date | Sat, 21 May 2022 22:22:03 +0200 | From | David Hildenbrand <> | Subject | Re: [RFC PATCH 0/6] Introduce Copy-On-Write to Page Table |
| |
On 21.05.22 22:12, Matthew Wilcox wrote: > On Sat, May 21, 2022 at 06:07:27PM +0200, David Hildenbrand wrote: >> I'm missing the most important point: why do we care and why should we >> care to make our COW/fork implementation even more complicated? >> >> Yes, we might save some page tables and we might reduce the fork() time, >> however, which specific workload really benefits from this and why do we >> really care about that workload? Without even hearing about an example >> user in this cover letter (unless I missed it), I naturally wonder about >> relevance in practice. > > As I get older (and crankier), I get less convinced that fork() is > really the right solution for implementing system().
Heh, I couldn't agree more. IMHO, fork() is mostly a blast from the past. There *are* still a lot of user and there are a couple of sane use cases.
Consequently, I am not convinced that it is something to optimize for, especially if it adds additional complexity. For the use case of snapshotting, we have better mechanisms nowadays (uffd-wp) that avoid messing with copying address spaces.
Calling fork()/system() from a big, performance-sensitive process is usually a bad idea.
Note: there is an (for me) interesting paper about this topic from 2019 ("A fork() in the road"), although it might be a bit biased coming from Microsoft research :). It comes to a similar conclusion regarding fork and how it should or shouldn't dictate our OS design.
[1] https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/
-- Thanks,
David / dhildenb
| |