Strawman proposal: making libthr default thread implementation?
Robert Watson
rwatson at FreeBSD.org
Wed Jul 5 09:02:40 UTC 2006
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
More information about the freebsd-threads
mailing list