From owner-freebsd-hackers Fri Feb 23 11:53:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA04043 for hackers-outgoing; Fri, 23 Feb 1996 11:53:19 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA04030 for ; Fri, 23 Feb 1996 11:53:16 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA23978; Fri, 23 Feb 1996 12:47:44 -0700 From: Terry Lambert Message-Id: <199602231947.MAA23978@phaeton.artisoft.com> Subject: Re: Linux/FreeBSD NFS performance. To: rminnich@Sarnoff.COM (Ron G. Minnich) Date: Fri, 23 Feb 1996 12:47:43 -0700 (MST) Cc: terry@lambert.org, hackers@FreeBSD.org In-Reply-To: from "Ron G. Minnich" at Feb 23, 96 12:47:20 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk > > Actually, this one is solvable using hot engine scheduling. They > > probably don't implement that yet, since they don't implement > > threading, but the overhead doesn't have to be as high as you think. > > terry, i think you're right, I'm in my 'every microsecond hurts' mode and > so anything looks bad. Any guesstimate as to how low it looks like they > can get it? The limit is going to be copy overhead. If they implement using a mux in the kernel for incoming packets, do hot engine scheduling off the mux, and mmap files that they serve, then the main bottleneck should be in disk overhead, since they save all the extra protection domain copies and the context switch overhead (assuming they are smart about rescheduling the same process and lazy saves of process state on context switch). That is, they should be able to come quite close to the current performance of FreeBSD, assuming they fix their disk drivers. FreeBSD has a couple of wins that could be incorporated as well. Eventually, when someone get kernel multithreading, I expect the request service engines could be realtime kernel threads. If you turn the packet around without any context switch whatsoever, that's probably as optimal as you could get. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.