[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mandrake 2.4.4 kernel



On Sun, May 20, 2001 at 08:15:21PM +0300, Alex Shnitman wrote:
> 
> > > 1. Much faster, thanks to a major optimization of the way fork-exec is
> > >    implemented.
> > 
> > IIRC, that feature's effects on the scheduler were not considered properly, 
> > and you could get all kinds of undesired scheduling behavior under 2.4.3, 
> > such as unresponsive processes and the like, and Linus reverted it in 2.4.4.
> 
> Actually 2.4.4 introduced this change, and it's been reverted in
> 2.4.5-pre1.

I stand corrected.

> I really don't understand how come it created problems though. Can
> anyone explain it? Why would user-level processes care about
> scheduling intricacies in the kernel? How is fork implemented in other
> Unix variants -- is it done the slow way in all of them?

The change was for the parent to give its child all of what remained of its
timeslice immediately after creating it. This way, when the scheduler gets 
called as the syscall exits, it figures out that the child ought to run 
before the parent gets the fork() return value. 

The problem is that although no userspace should make assumptions 
about scheduling, the scheduler itself is really a delicate system and has to
make lots of its own assumptions about userspace behaviour and about its own. 
If you have a lot of forks running, you've got a lot of worth of timeslices 
being handed around and concentrated in the hands of children, and that is a 
skew wasn't considered in the scheduler's original design.

IIRC neither FreeBSD nor OpenBSD do these child gifts. It's not necessarily
"the slow way", it just has advanteges in fork/exec situations. Anyhow, from
the reactions to the idea I guess it may be pretty novel in Unix in general -- 
otherwise someone would HAVE to mention that FooOS already does this with 
considerable performance advanteges, and Linus would respond that FooOS is a
piece of crap he wouldn't touch with a ten foot pole, and someone else would
point out that the Foo approach is much more scalable, which is why it's
preferred to Linux in all the serious companies HE knows, and we'd end up 
with the usual flamewar, not unlike the ones kuro5hin.org gets every time 
someone mentions that some story was already posted on Slashdot six weeks ago.

In any case, KT says one proposed solution was to give the child only two
thirds of the parnet's remaining timeslice, or something. I wonder why they
don't simply force a context switch to the child just after it's created 
instead of messing around with priorities... Any kernel hackers who care to 
comment?

=================================================================
To unsubscribe, send mail to linux-il-request@linux.org.il with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@linux.org.il