Re: SCHED_ULE should not be the default

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.

t23# cat /root/bin/t23stat
#!/bin/sh
echo -n "`date` "
sysctl dev.cpu.0.freq dev.cpu.0.cx_usage
sysctl dev.acpi_ibm | egrep 'fan_|thermal'
sysctl hw.acpi.thermal.tz0.temperature
acpiconf -i0 | egrep 'State|Remain|Present|Volt'

Sure it's a slow machine, but it normally runs pretty smoothly.
Anything with a bit of disk i/o, like buildworld, runs smooth as.

This is on 8.2-R GENERIC, HZ=1000, 768MB with lots free, no swap in use.  
I'll definitely be trying SCHED_4BSD after updating to 8-stable unless a 
'miracle cure' appears beforehand.

cheers, Ian