Date: Fri, 20 Sep 2002 03:04:39 -0700 From: Bill Huey (Hui) <billh@gnuppy.monkey.org> To: Julian Elischer <julian@elischer.org> Cc: freebsd-arch@freebsd.org, "Bill Huey (Hui)" <billh@gnuppy.monkey.org> Subject: Re: New Linux threading model Message-ID: <20020920100439.GB4207@gnuppy.monkey.org> In-Reply-To: <Pine.BSF.4.21.0209192345090.16925-100000@InterJet.elischer.org> References: <20020920031423.GA3380@gnuppy.monkey.org> <Pine.BSF.4.21.0209192345090.16925-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 20, 2002 at 12:08:38AM -0700, Julian Elischer wrote: > HI and thanks for the pointers. > > it's interesting that the features that they talk about > as being difficult and 'required' generally just "fall out" of the > KSE implimentation. A lot of the shortcomings of M:N that they > quote don't apply to the KSE schemes either.. Mingo's O(1) scheduler is pretty snazzy ( high brow technical term ;) ) with how it migrates/load balances tasks between various CPUs, maintains cache coherency, and their threading model can get immediate benefits from that feature on SMP machines. There's a lot of design tradeoffs that still need to be measured and balanced against one an other. Those are kind of unknowns in KSEs/libc_r at this point in time until folks get to that point. > They talk a lot about making signals per-process (uber-process that is). > Signals in KSE are automatically per process. > They talk of the difficulty of making SIGSTOP work, and are very > very proud that they have it working over the entire > uber-process, yet KSE has had this working since the > very first test program. I still think they are dressing up a Bull > to make it fit in in the chicken coop. How ? The bull being heavy weight kernel threading verses chickens being userspace threading ? Yeah, I'm curious how they implemented their signal handling myself and how their implementation differs from KSEs. It's badly needed and I'm glad they finally have this stuff. > The sad thing is that we'll have to implement their kernel side stuff > for binary compatibility, so we'll have chickens AND a bull dressed > like a bunch of chickens. Market share has it's advantages. > Of course We can emulate them but they'll never be able to emulate us. > You can make a bunch of chickens look like anything a bull dressed as > a bunch of chickens can look like, but the converse is not true without > killing the bull. > :-) Dude, that was PROFOUND. I think all that bad east bay area acid finally got to you from all that utter animal confusion. ;) either that or all of that plush toy abuse is finally making you pay the price. ;) The good thing about their stuff is that any future Linux emulator can be simplified, since they will finally conform to Posix signal handling and we'll get more Linux compatibility in that case automatically. That's assuming it gets implemented, of course. The obnoxious "SIGCHLD to signify thread death" stuff will finally be gone and other good things will replace it. Software with very heavy threading components like the JVM/HotSpot (ported and maintained by yours truely in FreeBSD ;) ) and Apache 2 can then be greatly simplified because of that... > Hell, if we've really screwed up, hey there's always 4.7 as a base :-) Na, I think the IO related upcalls are golden, but the preemption ones worry me because of the overhead. There are possible ways of getting around that which we talked about in the past (NetBSD dude at Usenix), shared event queue of some sort between the kernel and the UTS (userspace threading system) to be polled when ever the thread-kern gets entered... Who knows. I've got something brewing in my head about this, but I'm not comfortable enough to articulate it just yet... something with timers emulated in userspace driving the UTS at a frequency high enough to accurately sample the event status of the virtual processors. This is replace upcalls in that situation... Don't know, I could be utterly wacked about this, just thinking to myself out loud. > What they have decided to do is not a stupid move. But I disagree with It's a good political move on their part because of the orientation of their kernel community. Their kernel context switching time is very fast, 2x faster than NetBSD from what I saw, so it's probably a workable solution for them with something like their "futex" performance being the only funny question left unanswered. Our libc_r is kind of unfair in that category. ;) And I need to bitch about that to them, well, just because I'm that way. :) > some of their assertions. I first heard that method of doing threads > expounded by Kirk in the BSD4.4 internals class in 1992 (or was that > 91?). It sounded feasible then and it is stiff feasible. In fact > I remember discussing it with Linus once a long time ago at a USENIX > forum. (before he became hard to find under the crowds). We'll see, good luck !!! > I just happen to think that what we have will be very sweet when you see > it working. bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020920100439.GB4207>