SCHED_ULE should not be the default
arundel at freebsd.org
Sun Dec 18 10:26:00 UTC 2011
On Sun Dec 18 11, Alexander Best wrote:
> On Sun Dec 18 11, Andrey Chernov wrote:
> > 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.
> i've also experienced issues with ULE and performed several tests to compare
> it to the historical 4BSD scheduler. the difference between the two does *not*
> seem to be speed (at least not a huge difference), but interactivity.
> one of the tests i performed was the following
> ttyv0: untar a *huge* (+10G) archive
> ttyv1: after ~ 30 seconds of untaring do 'ls -la $direcory', where directory
> contains a lot of files. i used "direcory = /var/db/portsnap", because
> that directory contains 23117 files on my machine.
> measuring 'ls -la $direcory' via time(1) revealed that SCHED_ULE takes > 15
> seconds, whereas SCHED_4BSD only takes ~ 3-5 seconds. i think the issue is io.
> io operations usually get a high priority, because statistics have shown that
> - unlike computational tasks - io intensive tasks only run for a small fraction
> of time and then exit: read data -> change data -> writeback data.
> so SCHED_ULE might take these statistics too literaly and gives tasks like
> bsdtar(1) (in my case) too many ressources, so other tasks which require io are
> struggling to get some ressources assigned to them (ls(1) in my case).
> of course SCHED_4BSD isn't perfect, too. try using it and run the stress2
> testsuite. your whole system will grind to a halt. mouse input drops below
> 1 HZ. even after killing all the stress2 tests, it will take a few minutes
> after the system becomes snappy again.
> > --
> > http://ache.vniz.net/
More information about the freebsd-stable