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