pthread switch (was Odd KSE panic)
Daniel Eischen
eischen at vigrid.com
Tue Jul 6 13:22:42 PDT 2004
On Tue, 6 Jul 2004, Andrew Gallatin wrote:
>
> Julian Elischer writes:
> >
> >
> > On Tue, 6 Jul 2004, Andrew Gallatin wrote:
> >
> > >
> > > FWIW, inserting a pthread_yield() just before the ioctl call in the
> > > worker thread speeds things up quite a bit (100us -> 73us) in
> > > combination with kern.threads.virtual_cpu=1.
> >
> > what about with kern.threads.virtual_cpu untouched?
> > and what about with the hlt sysctl?
>
>
> kern.threads.virtual_cpu=2
> machdep.cpu_idle_hlt=1
>
> no yeild 123.6us
> yeild 116.8us
>
> kern.threads.virtual_cpu=2
> machdep.cpu_idle_hlt=0
> no yield 111.9
> yield 112.9
>
> kern.threads.virtual_cpu=1
> machdep.cpu_idle_hlt=1
> no yeild 100.8
> yeild 75.0
>
> kern.threads.virtual_cpu=1
> machdep.cpu_idle_hlt=0
> no yield 93.9
> ield 67.9
>
>
> > does your worker thread loop to check if there is more work before
> > waiting to be notified?
>
> Yes. He takes a mutex, loops over all completed events, sending
> pthread_signals as required, then releases the mutex and sleeps via
> an ioctl.
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().
--
Dan Eischen
More information about the freebsd-threads
mailing list