Re: Deadlock on fragmented memory?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 25 Oct 2017 01:36:29 +0000
    From:        Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>
    Message-ID:  <20171025013937.7C24760AF6%jupiter.mumble.net@localhost>

  | Mostly I expect it to be a lot of bookkeeping.  If I were doing it,
  | I'd probably use struct uio or similar so that I can easily uiomove to
  | incrementally set it up, [...]

What I have wanted to do for a long time, but never found the energy,
is to create a variant exec() which allows the arg data, and env data,
to be in separable pages, with a flag arg to allow the application to
tell the kernel that the arg/env data is in pages that can be handed
over (ie: no private data from the original process happens to be
in the same pages - the flag may be better expressed as an "end pointer"
to avoid issues where the application and the kernel don't agree just
how big a page is.)

Most applications would never bother, but the ones that do a lot of
running of other processes (say, sh, and probably make) could make use
of this and cut down on a lot of both data copying and page contention.

When used this way, the arg and env (separate) pages would simply be
removed from the calling processes VM (it doesn't care, it is vanishing,
if it is a vfork child, the pages would be made CoW and shared) and included
in the process being exec'd.

For a lot of processes the env is simply passed around untouched (perhaps
examined, but not altered) so this could save a lot of env copying and
duplication.

I am not under the illusion that this is (would be) a simple task, there
will be a lot of details to get right - many I have probably never
considered, but it always seemed a waste to me to copy data out of the
memory of a process that is about to be destroyed just so we can copy
it into the memory of a new process being created, when we could just
move the pages instead.

kre