Re: SCHED_ULE should not be the default

From: Andrey Chernov <ache_at_FreeBSD.ORG>
Date: Sun, 18 Dec 2011 11:52:42 +0400
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/
Received on Sun Dec 18 2011 - 06:52:50 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:22 UTC