Re: SCHED_ULE should not be the default
On Tue, Dec 13, 2011 at 10:40:48AM +0200, Ivan Klymenko wrote: > > On 12/12/2011 05:47, O. Hartmann wrote: > > > Do we have any proof at hand for such cases where SCHED_ULE performs > > > much better than SCHED_4BSD? > > > > I complained about poor interactive performance of ULE in a desktop > > environment for years. I had numerous people try to help, including > > Jeff, with various tunables, dtrace'ing, etc. The cause of the problem > > was never found. > > > > I switched to 4BSD, problem gone. > > > > This is on 2 separate systems with core 2 duos. > > > > > > hth, > > > > Doug > > > > If the algorithm ULE does not contain problems - it means the problem > has Core2Duo, or in a piece of code that uses the ULE scheduler. 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. -- http://ache.vniz.net/ ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: SCHED_ULE should not be the default
On Tue, Dec 13, 2011 at 02:22:48AM -0800, Adrian Chadd wrote: > On 13 December 2011 01:00, Andrey Chernov wrote: > > >> If the algorithm ULE does not contain problems - it means the problem > >> has Core2Duo, or in a piece of code that uses the ULE scheduler. > > > > 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. > > Are you able to provide KTR traces of the scheduler results? Something > that can be fed to schedgraph? Sorry, this machine is not mine anymore. I try SCHED_ULE on Core 2 Duo instead and don't notice this effect, but it is overall pretty fast comparing to that Pentium 4. -- http://ache.vniz.net/ ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: SCHED_ULE should not be the default
On Sun, Dec 18, 2011 at 05:51:47PM +1100, Ian Smith wrote: > On Sun, 18 Dec 2011 02:37:52 +, 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/ ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
