Date: Thu, 22 Oct 98 08:14:23 -0500 From: "Richard Seaman, Jr." <lists@tar.com> To: "Ville-Pertti Keinonen" <will@iki.fi> Cc: "current@freebsd.org" <current@FreeBSD.ORG> Subject: Re: Another Serious libc_r problem Message-ID: <199810221314.IAA00553@ns.tar.com>
next in thread | raw e-mail | index | archive | help
On 22 Oct 1998 13:19:51 +0300, Ville-Pertti Keinonen wrote: >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. FWIW, John Dyson posted a "kernel threads" implementation a couple of months ago. It wasn't anything close to a full pthreads implementation though. For the heck of it, I wrote a small program that spawned several threads, which just yielded back and forth among them, and compiled it under both the kernel threads and FreeBSD user threads. The kernel threads were about 2.2 times faster (could do 2.2 times more yields per seconds) than the FreeBSD user threads. I never tried to profile the reason, but the system calls are it, I'm sure. And, I didn't have any open file descriptors, so my code bypassed the extra system call to select that the user thread scheduler would do in that case. As to complexity, I've compared the Linux kernel threads implementation to the FreeBSD user threads. The FreeBSD implementation is much more massive, much more complex, and implements far fewer features. Most of the extra complexity is in the code dealing with handling blocking i/o, and would disappear with kernel threads. >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). Most likely, yes. >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. I agree completely. 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?199810221314.IAA00553>