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