Date: Mon, 10 Jul 2006 02:04:30 -0700 From: "Kip Macy" <kip.macy@gmail.com> To: "Robert Watson" <rwatson@freebsd.org> Cc: freebsd-threads@freebsd.org, Daniel Eischen <deischen@freebsd.org>, David Xu <davidxu@freebsd.org>, threads@freebsd.org, Julian Elischer <julian@elischer.org> Subject: Re: Strawman proposal: making libthr default thread implementation? Message-ID: <b1fa29170607100204q43a38aa7jfebe97eb18ca9e44@mail.gmail.com> In-Reply-To: <20060705095450.O64340@fledge.watson.org> References: <20060703101554.Q26325@fledge.watson.org> <200607042204.52572.davidxu@freebsd.org> <44AAC47F.2040508@elischer.org> <200607041819.05510.peter@wemm.org> <b1fa29170607042101q4a1204c7o942d83edcec71eb7@mail.gmail.com> <44AB4C22.3030109@elischer.org> <20060705095450.O64340@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Apart from real time scheduling functionality I have yet to see any
real-world technical deficiencies with libthr. I have, however, seen
major stability issues with KSE.
Network Appliance abandoned FreeBSD as a platform for running their
simulator due to frequent hangs caused by signals. More recently, on
sun4v, when single stepping csup (or any multi-threaded app for that
matter) the debuggee would often get the SIGTRAP and not GDB. When
re-starting mysqld for the second or third time the process would
become unkillable. These problems are not entirely surprising, KSE
makes signal handling *very* complicated. I am disappointed that
threads are currently unusable on sun4v with KSE.
I would be delighted if sometime in the very near future, one of the
following happened:
1.
a) Somebody steps up to work on KSE and fixes the signal issues that
have long plagued it. John Birrell or Paul Saab can make a T2000
available to any motivated developer.
2.
a) David Xu fixes static linking with libthr
b) David Xu exports support for real-time scheduling via libthr
c) Peter Wemm checks in bike_sched
The second seems much more logical, given our desire to become
performance competitive with Linux. However, sched_lock is not
currently FreeBSD's biggest bottleneck, and thus the first would be
acceptable. I would still be pleased at the possibility of sun4v
someday being checked into CVS.
-Kip
On 7/5/06, Robert Watson <rwatson@freebsd.org> wrote:
>
> On Tue, 4 Jul 2006, Julian Elischer wrote:
>
> > If it come to pass that M:N threads are judged to be "unsuitable" then that
> > is a decision that I can live with, but never be let it be said that I
> > walled FreeBSD in to only having the option of 1:1 threads.
>
> Given that I have serious hindsight accuracy problems, I won't even talk about
> my foresight issues. :-) I think we shouldn't nail the KSE coffin closed just
> yet -- as Peter has already said, it's one thing to do a skunkworks hack of
> what might eventually be used, but it's quite another to show that the
> perceived benefit maps into real world benefit. I'd like to see that clearly
> shown before we do anything drastic. In particular, we need to show that the
> benefit is there for more than just a few poorly written benchmarks, but also
> for a range of real-world workloads, and that the scheduler simplifications
> pay off in terms of both code complexity and our ability to optimize. I also
> want to make sure we understand some of the artifacts better: the benefit of
> reducing per-process lock contention is significant, and I'm interested in
> understanding where on the workload spectrum the benefits of 1:1 outweight the
> benefits of M:N a bit better. Is my interpretation that this is M:N providing
> better kernel workload management correct, or is it an artifact of scheduler
> behavior? And, where future hardware and application trends will push
> workload behavior with respect to the optimizations we already have, not to
> mention the ones we are considering.
>
> Robert N M Watson
> Computer Laboratory
> University of Cambridge
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b1fa29170607100204q43a38aa7jfebe97eb18ca9e44>