Strawman proposal: making libthr default thread implementation?

[Kip Macy]

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 at 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
>