Re: PATCH(?): linux-2.4.4-pre2: fork should run child first

["Adam J. Richter" <adam@yggdrasil.com>]

Rik van Riel <riel@conectiva.com.br> writes, regarding the idea
of having do_fork() give all of the parent's remaining time slice to
the newly created child:

>It could upset programs which use threads to handle
>relatively IO poor things (like, waiting on disk IO in a
>thread, like glibc does to fake async file IO).

	Good point.

[...]
>If it turns out to be beneficial to run the child first (you
>can measure this), why not leave everything the same as it is
>now but have do_fork() "switch threads" internally ?

	That is an elegant idea.  Not only would you save a few cycles by
avoiding what's left of the context switch, but, more imporantly, you
would be sure that no intervening process could be selected to run
between the parent giving up the CPU and the child running (which
could otherwise waste an additional full context swtich).  Also, you
then would not necessarily have to make the parent give up all of its
remaining time slice.  These two characteristics means that future
tweaks to the scheduler would be much less likely to accidentally
defeat running of the child first.

	As far code cleanliness goes, you get to delete a line
from do_fork ("current->need_resched = 1;"), but I think that's about
it.  You might even be able to avoid adding "current = p;" to do_fork
by having newly allocating task_struct assume the identity of the
parent and making the changes to "current", although I wonder
if anything else points to the current task or if that might
screw up any interrupts that occur during that process.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."