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>