Date: Fri, 27 Apr 2001 23:05:43 -0700 From: Julian Elischer <julian@elischer.org> To: Alfred Perlstein <bright@wintelcom.net> Cc: Terry Lambert <tlambert@primenet.com>, arch@FreeBSD.ORG, terry@lambert.org Subject: Re: KSE threading support (first parts) Message-ID: <3AEA5DB7.C9209955@elischer.org> References: <200104272306.QAA13810@usr02.primenet.com> <20010427160607.M18676@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: > > * Terry Lambert <tlambert@primenet.com> [010427 15:56] wrote: > > > > In other words, the complexity of the model which Jason Evans > > arrived at from the Big Threads Design Meeting in Foster City > > that about 120 of us attended, is optimal for achieving my > > design goals, without going to ascyn call gates. > > The way I envision async call gates is something like each syscall > could borrow a spare pcb and do an rfork back into the user > application using the borrowed pcb and allowing the syscall to > proceed as scheduled as another kernel thread, upon return it would > somehow notify the process of completion. well if that's async call-gates than we are doing Async call-gates.. it describes how a KSE system works.. here's how I see it. KSE does syscall. KSE blocks in syscall. KSE saves state into a KSEC. KSE returns with an upcall to the UTS. UTS schedules another thread. [time passes] Quantum is exhausted. KSE is pre-empted. Current user stack is munged to look like it did a yield() (unless in critical region) [time passes] Interrupt signals completion of original IO (interrupt level part). Associated KSEC is hung off the KSEG as 'runnable' (And KSEG put on run queue if not already there). [time passes] At next kernel scheduling event where that KSEG is made 'current', KSEC is loaded, syscall is completed and results writen back to process space. User stack is munged to look like the process did a yield() just after returning from syscall. After all runnable KSECs have been run to this state, an upcall is made to UTS reporting all threads that completed syscalls since last report. UTS schedules either suspended original thread or pre-empted thread. > > > IMO, going to async call gates could result in as much as an > > additional 25% improvement in performance. Unfortunately, it > > would also mean a lot of extra overhead to ensure binary > > backward compatability, since it would put all of the standard > > POSIX semantics into the libraries, and the default behaviour > > would be completely asynchronous. Binary compatability would > > mean using a different INT than INT 0x80 for system calls, and > > putting backward compatability cruft into a module to support > > any binary which some moron decided to link static because they > > thought that linking it static makes it somehow safer from single > > file damage failure than using libc.so and ld.so. > > > > My ideal implementation would use async call gates. In effect, > > this would be the same as implementing VMS ASTs in all of FreeBSD. > > Actually, why not just have a syscall that turns on the async > behavior? Basically I don't see the problem.. that's basically what we are doing.... > > > That all said, the current project, as it was envisioned by Jason > > Evans, does not have the limitations which you and Nate fear, > > unless you cop out on the implementation, and do what Julian and > > Archie wanted with KSEG non-migration of KSEs (and the concommitant > > single scheduler run queue for all CPUs), or if you take Matt's > > approach, and serialize execution everywhere, not just within a > > particular KSEG (Matt's approach prevents the need for a single > > process to be able to exist on a run queue as more than one entry > > instance, which makes some things easier). > > > > I would call both the Matt approach, and the Julian/Archie approach > > "overly conservative"; they are both in excess of 12 years behind > > the state of the Art. But I would also level the same criticism > > at using the 6 year old technology of scheduler activations to > > avoid going to true async call gates. define an aysnc call gate and show how it differs from what we are suggesting? We are suggesting that all blocking syscalls be made async. We are also suggesting a reporting mechanism by which completed syscalls are reported. > > > > > > In any case, you and Nate are getting upset at shortcuts that > > people want to take in implementation, not at the design itself. > > > > Cut it out. > > Well if we have an implementation where the implementators are > unwilling or incapable (because of time constraints, or getting > hit by a bus, etc) of doing the more optimized version then what's > the point besideds getting more IO concurrancy? I don't know, it > just that if someone has a terrific idea that seems to have astounding > complexity and they don't feel like they want to or can take the > final step with it, then it really should not be considered. Alfred, if you think this is astoudingly compex, then it shows you need to read it again.. I think it's very simple.. Blocking syscalls are allowed to return to user space via an upcall. Completed (previously blocked) syscalls are reported on scheduler events and possibly at other oportune times. (all of which would be some sort od kernel boundary crossing event) the rest of it is housekeeping to allow this to happen safely, fairly, and concurrently on multiple processors.. > > btw, I've read some on scheduler activations, where some references > on async call gates? > > -- > -Alfred Perlstein - [alfred@freebsd.org] > Represent yourself, show up at BABUG http://www.babug.org/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v 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?3AEA5DB7.C9209955>