Date: Tue, 6 Jul 2004 14:22:15 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Daniel Eischen <eischen@vigrid.com> Cc: freebsd-threads@freebsd.org Subject: Re: pthread switch (was Odd KSE panic) Message-ID: <Pine.BSF.4.21.0407061420420.64529-100000@InterJet.elischer.org> In-Reply-To: <Pine.GSO.4.10.10407061646580.15529-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 6 Jul 2004, Daniel Eischen wrote: > 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. It'd be interesting to see a kernel compiled with config -p and the result of the profiling.. (when nothing else is running.) I presume all teh debugging is turned off. > > > 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.BSF.4.21.0407061420420.64529-100000>