I like SCHED_4BSD

[Julian Elischer]

On Thu, 11 Mar 2004, Ian FREISLICH wrote:

> > 
> > 
> > On Thu, 11 Mar 2004, Ian FREISLICH wrote:
> > 
> > > > > o Better interactivity -- No mouse jerkiness, no sluggish screen update
> s =
> > > > when
> > > > >   switching between virtual desktops, etc.
> > > > >=20
> > > > > o Better scheduling!  I'm serious here.  Watching top under SCHED_ULE, 
> I'm
> > > > >   seeing 10, 15, 20 seconds go by where ALL processes are sleeping.=20
> > > > >   Processes seem to be spending inordinate amounts of time in the "kser
> el"
> > > > >   state.  This, of course, doesn't happen with SCHED_4BSD.
> > > > 
> > > > That this observation may well be bogus, because you're trying to
> > > > measure the scheduler using a tool that is itself run by the
> > > > scheduler, so the process stats you see may not be representative of
> > > > what is really happening on your system.
> > > 
> > > That point is taken, however, on my old SMP box _ULE adds an extra
> > > ~5000 seconds of wall clock time to a 'make buildworld -j8' compared
> > > to _BSD 'make world -j8'.
> > > 
> > > I did some tests about 3 weeks ago using bind-dlz and postgresql-7.4.1
> > > on this same machine trying libc_r and libkse using both schedulers.
> > > ULE results with either thread library were dismal ~.33 that of
> > > BSD: ULE gave about 17 authoritive lookups a second with BSD giving
> > > about 50.  The KSE library only dropped the rate by about 2 lookups
> > > per second on both schedulers which is essentially noise, but I had
> > > expected an improvement.
> > 
> > Re: KSE....
> > We have not yet begun to fight^H^H^H^H^Hoptimise
> > see what happens if you disable the halt on idle 
> > sysctl machdep.cpu_idle_hlt=0
> > The machine will get hotter but it may affect the outcome..
> > Just curious.
> 
> Do you think that this may also affect ULE?  BTW, the CPUs are
> already hot because they're continuously running the dnetc client.

I don't know about ULE but for 4BSD it can slow down KSE and libthr when 
work is scheduled to an otherwise idle CPU,



> 
> Ian
> 
> --
> Ian Freislich
>