Date: Fri, 27 Apr 2001 16:06:07 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Terry Lambert <tlambert@primenet.com> Cc: arch@FreeBSD.ORG, terry@lambert.org Subject: Re: KSE threading support (first parts) Message-ID: <20010427160607.M18676@fw.wintelcom.net> In-Reply-To: <200104272306.QAA13810@usr02.primenet.com>; from tlambert@primenet.com on Fri, Apr 27, 2001 at 11:06:01PM %2B0000 References: <200104272306.QAA13810@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* 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. > 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? > 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. > > > 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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010427160607.M18676>