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/
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
