From owner-freebsd-current  Sun Nov 28  8:34:45 1999
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id 0F823150A3
	for <current@FreeBSD.ORG>; Sun, 28 Nov 1999 08:34:35 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id IAA44858;
	Sun, 28 Nov 1999 08:34:16 -0800 (PST)
	(envelope-from dillon)
Date: Sun, 28 Nov 1999 08:34:16 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <199911281634.IAA44858@apollo.backplane.com>
To: Peter Wemm <peter@netplex.com.au>
Cc: David Greenman <dg@root.com>,
	Julian Elischer <julian@whistle.com>, current@FreeBSD.ORG
Subject: Re: Which is the truth? (sycalls and traps) 
References:  <19991128054519.2CB181C6D@overcee.netplex.com.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:
:I was rather suprised when I found out just how expensive kernel entry was
:some time ago..  What I was doing was a reentrant syscall that aquired no
:locks and ran about 5 instructions in kernel context..  Anyway, it took
:something like 300 times longer to do that (called via int $0x81) than to
:do a 'call' to equivalent code in userland.  Anyway, with overheads on that
:scale, whether we push 5 or 8 or whatever registers in the handler is
:almost lost in the noise.
:
:Cheers,
:-Peter

    Well, it could be 300x but that's like comparing a cache hit to a cache
    miss - in real terms a UP syscall takes, what, 1-3 uS?  An SMP syscall
    takes 6 uS.  This on a PIII-450.  Both times can be cut down to less
    then 500nS with fairly simple optimizations.  Unless you are doing 
    hundreds of thousands of context switches a second the overhead is in 
    the noise in real terms, and *definitely* in the noise if you tack on
    a task switch in the middle of that.

    Having the kernel do the context switch between threads has a huge number
    of advantages that should outweight or at least equal the minor increase
    in overhead.  A couple of points that have been brought up in recent 
    emails:

	* blockages due to VM faults

	* blockages due to file I/O (not even network I/O)

	* disk parallelism (thread A reads file block from kernel cache,
	  thread B reads file block and has a cache miss).

	* event synchronization

	* kernel state

    Even if one were to use an asynchronous call gate one then has to deal
    with the additional overhead imposed by the asynch call gate when a 
    syscall could have been run from the disk cache (that is, not block).  
    Personally speaking, I think async call gates are a huge mistake without
    a prioritized, vectorable software interrupt mechanism to go along with
    it.  The current unix signal mechanism is simply not up to the task.

    There are serious issues with async call gates including potential 
    resource hogging issues that frankly scare the hell out of me.  I would
    prefer a kernel stack for each thread and I would prefer a syscall to
    set a thread runnable/not-runnable.  Such a syscall could specify an
    optional cpu and optional run interval.

    There are simply too many things that a UP scheduler does not have access
    to - such as knowing whether a syscall can complete without blocking or
    not - to allow the UP scheduler to actually perform the context switch.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message