Date: Tue, 6 Jul 2004 16:22:34 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: freebsd-threads@freebsd.org Subject: Re: pthread switch (was Odd KSE panic) Message-ID: <Pine.GSO.4.10.10407061619220.10060-100000@pcnet5.pcnet.com> In-Reply-To: <16619.2082.399880.649617@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10407061619220.10060-100000>