Date: Sun, 18 Dec 2011 10:24:01 +0000 From: Alexander Best <arundel@freebsd.org> To: Andrey Chernov <ache@freebsd.org>, Ian Smith <smithi@nimnet.asn.au>, Bruce Cran <bruce@cran.org.uk>, Ivan Klymenko <fidaj@ukr.net>, Doug Barton <dougb@FreeBSD.ORG>, "O. Hartmann" <ohartman@mail.zedat.fu-berlin.de>, Current FreeBSD <freebsd-current@FreeBSD.ORG>, freebsd-stable@FreeBSD.ORG, freebsd-performance@FreeBSD.ORG Subject: Re: SCHED_ULE should not be the default Message-ID: <20111218102401.GA42627@freebsd.org> In-Reply-To: <20111218075241.GA45367@vniz.net> References: <4EE1EAFE.3070408@m5p.com> <4EE22421.9060707@gmail.com> <4EE6060D.5060201@mail.zedat.fu-berlin.de> <4EE69C5A.3090005@FreeBSD.org> <20111213104048.40f3e3de@nonamehost.> <20111213090051.GA3339@vniz.net> <4EED5200.20302@cran.org.uk> <20111218164924.L64681@sola.nimnet.asn.au> <20111218075241.GA45367@vniz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111218102401.GA42627>