Date: Tue, 6 Jul 2004 16:48:29 -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.10407061646580.15529-100000@pcnet5.pcnet.com> In-Reply-To: <16619.3035.165728.569632@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10407061646580.15529-100000>