Date: 22 Oct 1998 13:19:51 +0300 From: Ville-Pertti Keinonen <will@iki.fi> To: Alfred Perlstein <bright@hotjobs.com> Cc: current@FreeBSD.ORG Subject: Re: Another Serious libc_r problem Message-ID: <863e8guce0.fsf@not.oeno.com> In-Reply-To: Alfred Perlstein's message of "20 Oct 1998 23:10:32 %2B0300" References: <Pine.BSF.4.05.9810201223390.18282-100000@porkfriedrice.ny.genx.net.newsgate.clinet.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein <bright@hotjobs.com> writes: > As a side note, has anyone thought of hybrid kernel+userland threads? > Basically a userland scheduler with kernel hooks for mutexes and > distributing signals. At startup or on the first pthread_create() the > pthreads library would sysctl out the number of processors in the > system and prefork kernel threads for each. The kernel threads would only > be active on SMP machines, otherwise there really is no point. Does > anyone have any papers/webpages about an algorithm like that? I'm not sure what you mean by kernel hooks for mutexes and signals, in most cases mutexes are the last thing you want the kernel to know about...but what you're suggesting mostly sounds like simply adding a kernel threads capability and primarily using user threads with code similar to the current system except that multiple kernel threads would be allocated for the user threads if it would allow for actual concurrency (SMP). This wouldn't really require a lot of changes in the thread code, but is, in my opinion, a bad idea. (A sort of similar approach is used by Mach cthreads, but it works better for various reasons that don't apply to FreeBSD) The problem I see with this picture (as well as the current one) is that a supposed advantage of userland threads, performance, often is not applicable. How can performance be measured? It isn't trivial. One quite significant factor is switching between threads. Not just running the scheduling algorithm but the changes in context. In terms of switching performance, well-implemented kernel threads can match or outperform any userland threads that need to perform any system calls while performing the switch. On the other hand, a userland thread implementation that doesn't perform system calls can be faster by several orders of magnitude, but either is broken or requires movement of some of the "system" behavior to a user-level. FreeBSD currently has the slowest alternative, userland threads that perform system calls while doing just about anything... I think it's at *least* four for a thread switch. In the absence of the ability to tell the thread system "I-don't-give-a-damn-about-signals", "gimme-crude-scheduling" etc., user-level threads are actually killing performance and adding complexity. Even if signals could be ignored, the overhead of polling the kernel for I/O is still difficult to avoid if there are threads waiting for something other than other threads and cpu cycles. There are, of course, other reasons for considering kernel threads undesirable, such as the fact that the kernel might need to keep much of the thread info in wired-down memory, as well as the fact that there is a restricted set of scheduling semantics available. For reasonable user-level thread performance, some kind of addition to the kernel API would be needed that could perform all of the kernel actions required for a thread switch (and, if possible, other thread ops) in one system call (any more and performance-wise, you'd very likely be better off using kernel threads). This is still not the same thing as kernel threads, since the controlling semantics and thread context structures could still be at a user level. In a hybrid system where the kernel "knows" about user threads (not actively, but with the ability to "react" to them), something like this would be a rather natural part of the hybrid API. But it could be done without kernel threads, as well. The belief that the current thread system is fine as long as you don't want to take advantage of SMP requires a rather unconservative definition of "fine". In many respects, plain kernel threads would be better than the current system (simpler, faster), unless the primary concern is saving kernel memory. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?863e8guce0.fsf>