SCHED_ULE should not be the default

[Alexander Best]

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.
> 
> +1
> 
> 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
                                                    s/portsnap/portsnap\/files/

>        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.
> 
> cheers.
> alex
> 
> > 
> > -- 
> > http://ache.vniz.net/