SCHED_ULE should not be the default
ache at FreeBSD.ORG
Sun Dec 18 07:52:50 UTC 2011
On Sun, Dec 18, 2011 at 05:51:47PM +1100, Ian Smith wrote:
> On Sun, 18 Dec 2011 02:37:52 +0000, Bruce Cran wrote:
> > On 13/12/2011 09:00, Andrey Chernov wrote:
> > > I observe ULE interactivity slowness even on single core machine (Pentium
> > > 4) in very visible places, like 'ps ax' output stucks in the middle by ~1
> > > second. When I switch back to SHED_4BSD, all slowness is gone.
> > I'm also seeing problems with ULE on a dual-socket quad-core Xeon machine
> > with 16 logical CPUs. If I run "tar xf somefile.tar" and "make -j16
> > buildworld" then logging into another console can take several seconds.
> > Sometimes even the "Password:" prompt can take a couple of seconds to appear
> > after typing my username.
> I'd resigned myself to expecting this sort of behaviour as 'normal' on
> my single core 1133MHz PIII-M. As a reproducable data point, running
> 'dd if=/dev/random of=/dev/null' in one konsole, specifically to heat
> the CPU while testing my manual fan control script, hogs it up pretty
> much while regularly running the script below in another konsole to
> check values - which often gets stuck half way, occasionally pausing
> _twice_ before finishing. Switching back to the first konsole (on
> another desktop) to kill the dd can also take a couple/few seconds.
This issue not about slow machine under load, because the same
slow machine under exact the same load, but with SCHED_4BSD is very fast
to response interactively.
I think we should not misinterpret interactivity with speed. I see no big
speed (i.e. compilation time) differences, switching schedulers, but see
big _interactivity_ difference. ULE in general tends to underestimate
interactive processes in favour of background ones. It perhaps helps to
compilation, but looks like slowpoke OS from the interactive user
More information about the freebsd-stable