Date: Fri, 16 Feb 2001 00:03:39 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: seth@pengar.com (Seth Leigh) Cc: tlambert@primenet.com (Terry Lambert), freebsd-smp@FreeBSD.ORG Subject: Re: possible problem with SMP? Message-ID: <200102160003.RAA10529@usr08.primenet.com> In-Reply-To: <5.0.2.1.0.20010215025043.027a3008@hobbiton.shire.net> from "Seth Leigh" at Feb 15, 2001 02:56:07 AM
next in thread | previous in thread | raw e-mail | index | archive | help
Please do not quote entire articles, particularly _after_ your comments, when responding in the future; thanks. 8-). > I just read pages 407 to 410 of the Jim Mauro/Richard McDougall "Solaris > Internals" book and it talks specifically about scheduler > activations. They mention how they are used by the kernel scheduler to > keep LWPs from a given process running throughout the rest of their quantum > even when one of them blocks, and some other things. They specifically > talk about Solaris Doors as being the mechanism by which the kernel calls > up into the threads library. I will have to read a lot more in the next > day or so about Solaris scheduler activations until I know exactly what > they are and what they do. I am still only on page 150 of the book. It's > not easy reading. ;-) But I will finish reading it, and then I will read > it all the way through again, since I really do want to understand this stuff. > > Terry, have you looked into the Solaris Doors mechanism, and do you think > that implementing a facility like that in FreeBSD would clean up and > improve the way FreeBSD plans to implement the threads library upcalls, and > other possible places for upcalls as well? Despite my as-yet limited > understanding, it sounds promising to me. I have looked at the mechanism. I think you will find that they are a Solaris 2.7 introduction, but am willing to be wrong. Doors are interesting. The thing they most resemble is a VMS asynchronous system trap, or an NT I/O completion routine. The DEC MTS system (Multi Threading Service), which was, as far as I am aware, an internal DEC product shared with only a few vendors, including my then employer, Novell, used ASTs in order to implement a simple call conversion threading library. It was superior to that in BSD, in that operations were not prevented and retried, which is an unnecessary protection domain crossing. The DEC code also was missing a number of obvious primitives, including timers and interlocks, for which VMS provided AST enabled routines; in the course of porting Mentat threads to VMS, I has to add these facilities to the threading system in order to support IPX, SPX, and the NPC streams mux. Other than typing in VMS sources from microfiche in order to fix bugs in the printer symbiont and the CTERM protocol handler, this was my first time out as a paid BLISS programmer. 8-). Where does Solaris' Doors mechanism have it over on other call conversion enabling technology? I'd have to say that it has it because it exists _simultaneously_ with the other mechanisms. The Doors paradigm is fundamentally similar to the signal code, in that it runs on a seperate stack, but can be triggered without having to go through a trampolie. Fundamentally, this means I cross U->K to set things in motion, then K->U, back to my program, once I have started rolling. Later, after the ball gets to the bottom of the hill, the kernel triggers a door, which runs K->U, causes some code to run, and then jumps bad U->K, when it's done. Why is it called a Door? All I can guess is that someone spent too much time writing PC BBS code in their youth. 8-). An astute observer will note that the number of protection domain crossings for this is 4; this is the same number we have for the other more advanced mechanisms. It's also the same number we have for the non-blocking I/O call conversion scheduler, if we assume that the first call always fails. If we don't make that assumption, then it's actually more than that approach (this doesn't make the approach better, since there is a loss of I/O concurrency; philosophically, it's the same thing as the difference between soft updates and DOW). In contrast, an async call gate mechanism has 2 domain crossings in all cases (asuming a doubly mapped call competion status structure). From a generic perspective, yes, this would simplify the FreeBSD activation upcall, and it could be useful in terms of the ability to write user space daemons that would handle processing of some kernel events (an external pager would be one example). Whether the code simplification would be worth it really depends on how the completion communication is handled for activations; it should be possible to drop it to 3 domain crossings per activation with the current BSD plans. It would certainly drop the complexity in the case that the user space code was in the user space scheduler at the time of the process being involuntarily preempted (instead of being in a "safe" region). This alone might justify the code, without having to appeal to the "think what you could do later!" crowd. ...Again, all IMO, of course. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102160003.RAA10529>