Date: Wed, 5 Jul 2006 10:02:39 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: freebsd-threads@freebsd.org, Daniel Eischen <deischen@freebsd.org>, kmacy@fsmware.com, David Xu <davidxu@freebsd.org>, threads@freebsd.org Subject: Re: Strawman proposal: making libthr default thread implementation? Message-ID: <20060705095450.O64340@fledge.watson.org> In-Reply-To: <44AB4C22.3030109@elischer.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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?20060705095450.O64340>