Date: Fri, 23 Feb 1996 12:47:43 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: rminnich@Sarnoff.COM (Ron G. Minnich) Cc: terry@lambert.org, hackers@FreeBSD.org Subject: Re: Linux/FreeBSD NFS performance. Message-ID: <199602231947.MAA23978@phaeton.artisoft.com> In-Reply-To: <Pine.SUN.3.91.960223124558.17092D-100000@terra> from "Ron G. Minnich" at Feb 23, 96 12:47:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602231947.MAA23978>