Date: Wed, 30 Jun 1999 10:47:54 -0500 (EST) From: Alfred Perlstein <bright@rush.net> To: smp@freebsd.org Cc: tlambert@primenet.com Subject: async call gates Message-ID: <Pine.BSF.3.96.990630102649.14320b-100000@cygnus.rush.net>
next in thread | raw e-mail | index | archive | help
Mr Lambert, I noticed you've been pushing for async call gates functionality in FreeBSD. I have several assumptions about how this would work that makes it expensive to accomplish, perhaps you or someone on this list can clarify by explanation and/or a URL to some paper or a book reference. Ok, here we go. I assume that an async call gate referes to having kernel threads. When a process performs a system call, once it enters the kernel it spinlocks on a queue then adds a "work node" to it describing what work it needs done. After the work is queued a kernel thread that just finished on another process' "work node" may pick it up and run the appropriate code to accomplish the work detailed in the node. The work node that is built would also describe certain things for the kernel thread: 1) process ID 2) needs a wakeup after completion 3) operation to perform 4) operation args 5) pointer to process statistics (notably u-area and such) The way I think that you are anticipating this improving things is that it's easier for these kernel threads to sync with each other than if all processes were able to enter deep into the kernel, it would also reduce lock contention, and as you said "process issues an async read, after the syscal the process finds itself on CPU0 while the kernel thread processing this on CPU1" While I agree that kernel threads would work to make aio_* work better there's the problem of many additional context switches to get work done per syscall, but that depends somewhat on the implementation. 1) process issues system call (context switch) 2) process must sleep waiting for kernel thread to return with work 3) process is woken up after work is completed 4) process goes back to usermode right now switches 2 and 3 don't happen, can this methodology really save so much in the future? *this has been a test of the emergency assumption test* *if the writer really understood what you were talking* *about he woulda kept quiet* Just an ISBN number, or URL to some paper explaining this would be really great. Thanks. -Alfred Perlstein - [bright@rush.net|bright@wintelcom.net] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ 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?Pine.BSF.3.96.990630102649.14320b-100000>