Date: Sat, 25 Jan 2003 22:06:48 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: 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: <20030125220607.Y18109-100000@mail.chesapeake.net> In-Reply-To: <200301252350.h0PNo6xO009489@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 25 Jan 2003, Matthew Dillon wrote: > 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. > Ah, yeah, very good. I hadn't considered the fork/exit priority adjustments in this light. I did have a big XXX there to look at this later though. I'll see if I cant do something more similar to the 4bsd code here. Thanks, Jeff 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?20030125220607.Y18109-100000>