Date: Sat, 25 Jan 2003 15:50:06 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Jeff Roberson <jroberson@chesapeake.net>, Steve Kargl <sgk@troutmask.apl.washington.edu>, Robert Watson <rwatson@FreeBSD.ORG>, Gary Jennejohn <garyj@jennejohn.org>, <arch@FreeBSD.ORG> Subject: Re: New scheduler (#2) Message-ID: <200301252350.h0PNo6xO009489@apollo.backplane.com> References: <20030125171217.D18109-100000@mail.chesapeake.net> <200301252320.h0PNKVoq090077@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I found another problem. In sched_exit() you are 'returning'
part of the child's priority and interactivity to the parent, but
you are not taking into account batch processes.
A batch child which is exiting, such as the 'cc1' in a 'cc' or the 'cc'
in a 'make' (you see where this is leading? Consider a 'make buildworld')
must penalize the parent so the next fork/exec'd child retains the batch
priority.
The 4bsd code does this. The sched_smp code does not. The sched_smp
code simply adds to kg_slptime and this can *never* penalize the parent.
The result is that the parent retains its near-zero cpu utilization
(because all it is doing is fork/exec/wait).
This could be the primary cause of the interactive/buildworld latency
reports.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301252350.h0PNo6xO009489>