All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Fremlin <chief@bandits.org>
To: "Adam J. Richter" <adam@yggdrasil.com>
Cc: <linux-kernel@vger.kernel.org>, <torvalds@transmeta.com>
Subject: Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
Date: 14 Apr 2001 02:54:08 +0100	[thread overview]
Message-ID: <m2g0fc6ybj.fsf@boreas.yi.org.> (raw)
In-Reply-To: <200104132351.QAA05523@adam.yggdrasil.com>
In-Reply-To: "Adam J. Richter"'s message of "Fri, 13 Apr 2001 16:51:34 -0700"

"Adam J. Richter" <adam@yggdrasil.com> writes:

> "John Fremlin" <chief@bandits.org> writes:
> > "Adam J. Richter" <adam@yggdrasil.com> writes:
> >> 	Guess why you're seeing this email.  That's right.  Linux-2.4.3's
> >> fork() does not run the child first.
> 
> >[...] If an app wants to fork and exec, it
> >should use *vfork* and exec, which is a performance win across many
> >OSs because the COW mappings don't even have to be set up, IIRC.
> 
> Even in that case, you want to run the child first because

The parent is not allowed to run until the child execs, if I
understand correctly. Read up on CLONE_VFORK.
 
[...]

> Of course, in the vfork case, this change is probably only a very
> small win.  The real advantage is with regular fork() followed by an
> exec, which happens quite a lot.  For example, I do not see vfork
> anywhere in the bash sources.

If it is a real advantage you can get a bigger advantage by changing
the app to use vfork, i.e. you can solve the problem (if it exists)
better without hacking the kernel. Further, your change will hurt
those apps which expect the parent to be given a fair chance, so
you'll need to add a fairfork(2) syscall to comply with Californian
anti age discrimmination legislation (humour). In fact, if you think
fork+exec is such a big performance hit why not go for spawn(2) and
have Linus and Al jump on you? ;-)

[...]

-- 

	http://www.penguinpowered.com/~vii

  reply	other threads:[~2001-04-14  1:55 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-13 23:51 PATCH(?): linux-2.4.4-pre2: fork should run child first Adam J. Richter
2001-04-14  1:54 ` John Fremlin [this message]
2001-04-14  2:29   ` Linus Torvalds
2001-04-14  2:51     ` Alexander Viro
2001-04-14  2:52     ` Ulrich Drepper
  -- strict thread matches above, loose matches on Subject: below --
2001-04-14 16:11 Adam J. Richter
2001-04-14  7:58 Adam J. Richter
2001-04-14  8:42 ` Michael O'Reilly
2001-04-14  9:00 ` Linus Torvalds
2001-04-14 15:06   ` Rik van Riel
2001-04-14  2:45 Adam J. Richter
2001-04-13 16:28 Hubertus Franke
2001-04-12 19:45 Adam J. Richter
2001-04-12 19:15 Adam J. Richter
2001-04-12 13:44 Hubertus Franke
2001-04-12  8:55 Adam J. Richter
2001-04-12 12:38 ` Horst von Brand
2001-04-17  9:15   ` Éric Brunet
2001-04-17 14:26     ` Jesse Pollard
2001-04-17 15:32       ` Éric Brunet
2001-04-13 21:08 ` John Fremlin
2001-04-14  3:53 ` Rik van Riel
2001-04-14  4:40   ` Linus Torvalds
2001-04-14 13:35     ` Rik van Riel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2g0fc6ybj.fsf@boreas.yi.org. \
    --to=chief@bandits.org \
    --cc=adam@yggdrasil.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.