Date: Sat, 28 Oct 2006 20:55:59 -0700 From: Julian Elischer <julian@elischer.org> To: David Xu <davidxu@freebsd.org> Cc: peter@freebsd.org, Daniel Eischen <deischen@freebsd.org>, gnn@freebsd.org, Kip Macy <kmacy@fsmware.com>, threads@freebsd.org Subject: My suggested path for threading. Message-ID: <4544264F.5050703@elischer.org> In-Reply-To: <200610290815.25252.davidxu@freebsd.org> References: <m2ejssstiw.wl%gnn@neville-neil.com> <Pine.GSO.4.64.0610281018130.12299@sea.ntplx.net> <m23b98ryth.wl%gnn@neville-neil.com> <200610290815.25252.davidxu@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I suggest that we remove the fairness code. that will remove a lot of the complexity. then both libraries will be more independent of each other and the scheduler. libpthread will have system and process scope threads. libthr will have only system scope threads but will probably be the more efficient library for the larger set of processes, while libpthread will be more efficient for a smaller set. Given this, I suggest the following path: 1/ remove the fairness code.. I can do this in the 2nd part of next week. I will be on vacation then. 2/ When it is up to it, make libthr the default threading library. I say this because MOST threading applications are very simplistic in their use of threading and the simpler threading infrastructure for 1:1 threading allows for easier optimisation. They usually use threading for IO parallelization and in this case, 1:1 and M:N devolve to effectively the same thing except that M:N has more overhead. 1:1 is more efficient in this case. 3/ Keep libpthread around. I believe strongly that there is a class of threaded app where M:N (after optimization) can leave 1:1 in the dust. This class of program instantiates many objects, each of which has a backing thread to implement some form of active behaviour. These threads usually never go to the kernel and typically come to life from a mutex or condition variable and then go to sleep again waiting on same. I have seen a test example of this class where M:N gave an order of magnitude speed up. 4/ continue to adhere VERY STRONGLY to our current practice of making the libraries RUN_TIME COMPATIBLE. (i.e. libmap can switch between them) I strongly believe that the problems people have reported with "KSE" are not problems with M:N threading as they are not using M:N threading but problems with the complexity added to the scheduler by the fairness attempt. I believe removing this will almost certainly fix those problems and if it doesn't it will narrow the search significantly.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4544264F.5050703>