On Sun, Sep 22, 2024 at 04:47:33PM -0500, Jay F. Shachter wrote:
>
> >
> > It's an exact copy, all memory allocations remain the same.
> >
>
> Please forgive the pedantic correction, but, although I don't know how
> OpenBSD does it, I certainly hope that OpenBSD does it the way other
> operating systems do it: the memory in the child process is not "an
> exact copy" -- the memory is not copied at all, but it is marked "copy
> on write" so that a copy of a page will be made when either the parent
> or the child alters it. But as long as neither parent nor child
> alters the memory there is no need to make a copy of it. Certainly if
> the fork() will be followed soon afterward by an exec(), copying all
> that memory which is all going to be freed up a microsecond later
> anyway would be folly.
>
> Similarly, a later poster made a comparison to a file copy: there are
> now two copies of a file, altering one does not alter the other. Now
> again, I don't know how the native OpenBSD filesystem does it, but I
> hope that (at least as a mount or tunefs option, you might not want it
> in every case) the native OpenBSD filesystem does it the way ZFS and
> other proper filesystems do it: the data blocks are not copied, but
> they are marked "copy on write" and a copy is made when either file is
> altered. As long as neither file is altered, there is no need to copy
> the data blocks on which the file resides.
>
> And yes, I do know that OpenBSD refuses to support ZFS, because
> OpenBSD is terrified of the patent, or maybe it's a copyright, even
> though FreeBSD and NetBSD have no fear of it. But I digress.
>
Indeed, these are digressions. What you are talking about are
implementation details/optimizations. From a userland memory
management perspecive, it does not matter if your process virtual
memory is copy-on-write or not. Same for filesystems. It's the
kernel's job to abstract these differences away, and it a good thing a
userland developer does not have to worry about cow.
-Otto
No comments:
Post a Comment