Date: Wed, 30 Jun 1999 22:27:17 -0700 From: John Milford <jwm@CSUA.Berkeley.EDU> To: Terry Lambert <tlambert@primenet.com> Cc: smp@FreeBSD.ORG Subject: Re: async call gates Message-ID: <199907010527.WAA07072@soda.CSUA.Berkeley.EDU> In-Reply-To: Message from Terry Lambert <tlambert@primenet.com> of "Thu, 01 Jul 1999 01:00:36 -0000." <199907010100.SAA13352@usr09.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert <tlambert@primenet.com> wrote: > > At the simplest level, there are three kinds of system calls: > > 1) Calls that will never block > 2) Calls that will always block > 3) Calls that may or may not block > > It would be trivial to add a flag to the sysent[] structure for > each system call to indicate what category it was in, if you had > a mind to optimize behaviour for type #1 calls. > > > Now for each system call, there is some context: > > 1) The calling process' address space > 2) Certain aspects of the calling process, unrelated to the > address space, per se. This is a subset of the contents > of the proc structure: credentials, PID, etc. > 3) A kernel stack > 4) A list of system resources, accumulated as they are held > > > This arrangement is symmetric between the kernel and user space, > as we will see below. > > > Now for the process model in user space. > > Let's assume that all existing system calls which are of type "will > always block" or of type "may or may not block" can now be executed > asynchronously, and that this is not an attribute of a particular > system call, but is an attribute of the call mechanism itself. We > might also place in this category some of the "will never block" > calls, if they take "a long time" to complete. > > This, in a nutshell, is the "async call gate". > . . . > > The advantage of this threads model over a kernel threads model > is that, so long as we have work pending, we can utilize the > full measure of our CPU quantum without taking a full context > switch overhead. This was the original promise that the threads > model made to us when it first appeared, and then renigged upon > when threads moved into the kernel. > I have been working recently on an async syscall mechanism that sounds somewhat like what you are discussing here. Part of the reason I would like to have it is that I am unsure of exactly how much it will buy performance wise. The implementation I am working on does what I call "lazy async", meaning that the syscall proceeds until it is about to block, and at this time it does a customized fork, the parent returns to user space, and the child proceeds to wait, and finish the call. This involves adding an extra paramater to all the syscalls for notification, bu that is an implementation detail. When I first started on this I thought the performance increase in using this mechanism with an appropriate userland thread package over using KSE's would be substantial. But now I'm not so sure, the reason being that this still creates a lot of precesses/kernel-threads (assuming a large sizable percentage of syscalls are going to block at some point). It may however save us from making as many VM switches. The only other optimizations I could come up with were to not save FP state when context switching from kernel async worker threads (and conversely not restore it when switching back), and more importantly to do lazy VM switches for the async workers meaning that instead of switching the VM space when switching to an async worker, the switch could be done when/if a copyin/copyout is done. Does this sound like a reasonable approach? Has anyone tried this before and gotten positive results? Is there a known better approach to this? --John 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?199907010527.WAA07072>