pthread switch (was Odd KSE panic)

[Andrew Gallatin]

Daniel Eischen writes:
 > On Tue, 6 Jul 2004, Andrew Gallatin wrote:
 > 
 > > 
 > > Daniel Eischen writes:
 > >  > Note that he is holding the mutex while calling pthread_cond_signal().
 > >  > If we enable preemption in pthread_cond_signal(), then I suspect it
 > >  > would be even worse than without preemption.
 > >  > 
 > >  > I think the only place where it is sane to enable preemption is
 > >  > on pthread_mutex_unlock().
 > > 
 > > That certainly makes sense to me.  But I don't want to see you
 > > optimize the threads lib just for my app.   I can always put in an
 > > #ifdef FreeBSD
 > > pthread_yield()
 > > #endif
 > > 
 > > But what I'm still wondering is where the ~3x slowdown (20usec linux
 > > -> ~60usec, libthr) is coming from.  Is this a factor of the context
 > > switch time and ithreads?
 > 
 > I suspect our kernel is butt-slow compared with Linux in general.
 > Mysql under native linux is similarly faster.

The butt-slowness is why I always whine about performance :-(

 > > I need to move the driver to a fast interrupt and I need to test
 > > SCHED_BSD as well.  I should probably cvs update to get jhb's
 > > scheduling changes.

With jhb's preemption changes, SCHED_4BSD, machdep.cpu_idle_hlt=0,
kern.threads.virtual_cpu=1, pthread_yield(), and a partridge in a
pear tree, I can get it down to 48us with KSE.  Best for libthr is now
57us.

This is apples to oranges, because of the ULE/BSD and preemption
changes.  So I'll wait until ULE works before trying to see if the
change was preemption..

Drew