Date: Tue, 23 Mar 2004 08:15:43 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Dmitry Morozovsky <marck@rinet.ru> Cc: freebsd-stable@freebsd.org Subject: Re: Urk, I take it back (was Re: Bug in p_estcpu handling onprocess exit in FBsd-4.x) Message-ID: <200403231615.i2NGFhue012286@apollo.backplane.com> References: <200403201941.i2KJf6Ml095658@apollo.backplane.com> <200403202244.i2KMiRth096273@apollo.backplane.com> <20040323152935.A3107@woozle.rinet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
:In case abyone interested the patch for stable as of today is attached.
:
:Sincerely,
:D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
That looks good.
One additional note: this has been working extremely well for us so
far. I can run make -j 8 buildworld's on my workstation and X remains
completely smooth. One person complained about mpg321 becoming
jerky in the face of a make -j 8. But I'm not sure there is an easy
way for any scheduler to check for that case since on a slow machine
mpg321 is essentially cpu bound (though perhaps the kernel could flag
processes talking to particular devices). Nicing it down to -1, or
nicing the buildworld to +1, solves the problem.
This scheduler change also has the interesting side effect of exposing
bugs in make -j n buildworld's (missing .ORDER's and dependancies)
because new child processes do not get cpu instantly. I just recently
made a bunch of mostly minor commits to DFly to correct most of
buildworld's parallel-make issues. Without the changes things like
mkdir -p in crypto and helper-generated header files would race and
one out of every 6 -j 4 buildworlds would fail. With the changes I
have so far been able to run through 40 -j 4 buildworlds without error.
-Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403231615.i2NGFhue012286>