From owner-freebsd-smp  Wed Jun 30 22:30:10 1999
Delivered-To: freebsd-smp@freebsd.org
Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52])
	by hub.freebsd.org (Postfix) with ESMTP id 95DDA14D46
	for <smp@FreeBSD.ORG>; Wed, 30 Jun 1999 22:30:06 -0700 (PDT)
	(envelope-from jwm@CSUA.Berkeley.EDU)
Received: from soda.CSUA.Berkeley.EDU (localhost [127.0.0.1]) 
	by soda.CSUA.Berkeley.EDU (8.8.8/) via ESMTP id WAA07072; Wed, 30 Jun 1999 22:27:17 -0700 (PDT)
        env-from (jwm@CSUA.Berkeley.EDU)
Message-Id: <199907010527.WAA07072@soda.CSUA.Berkeley.EDU>
To: Terry Lambert <tlambert@primenet.com>
Cc: smp@FreeBSD.ORG
Subject: Re: async call gates
In-reply-to: Message from Terry Lambert <tlambert@primenet.com>
             of "Thu, 01 Jul 1999 01:00:36 -0000."
             <199907010100.SAA13352@usr09.primenet.com>
Date: Wed, 30 Jun 1999 22:27:17 -0700
From: John Milford <jwm@CSUA.Berkeley.EDU>
Sender: owner-freebsd-smp@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

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