SCHED_ULE should not be the default
Andrey Chernov
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
experience.
--
http://ache.vniz.net/
More information about the freebsd-performance
mailing list