From owner-freebsd-arch Thu May 25 9:26:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 554A637C812 for ; Thu, 25 May 2000 09:26:41 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA82954; Thu, 25 May 2000 09:26:37 -0700 (PDT) (envelope-from dillon) Date: Thu, 25 May 2000 09:26:37 -0700 (PDT) From: Matthew Dillon Message-Id: <200005251626.JAA82954@apollo.backplane.com> To: Chuck Paterson Cc: Andrew Gallatin , arch@FreeBSD.ORG Subject: Re: Short summary References: <200005251502.JAA24170@berserker.bsdi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :}I'm curious about tortuous workloads like a firewall between multiple :}100Mb or Gigabit network segments, or a saturated Web (or NFS) server :}w/multiple disk controllers and network adapters (Eg, workloads like :}the imfamous Mindcraft benchmark (in single CPU mode), or SPEC SFS97 :}or SPEC WEB99). :} : : We currently run NFS under a single lock. I have no :clue when we BSDI will do anything about this. The NFS code which :is in both FreeBSD and BSD/OS is going to have a major wacking to :multi thread it. There are structural problems which are not present :in the other file systems. Something is going to have to be done :with the huge inline macros so they know what mutex to release. :The sharing of macros between server and client makes it even :harder. On a related subject talk about blowing cache lines for nothing. :I have done just a very few tests and server and client appear to be just :slightly faster. The client was (3.5% in one test) in the test I :still have numbers for. :... :Chuck I'd argue that we should ignore NFS at least until after the NIC interrupts are made SMP safe. Just fixing the NIC itnerrupts alone will at least double NFS's performance. Not only do the NFS macros make things difficult (even with the cleanups I did last year!), but NFS also has a tendancy to setup I/O's in one process and complete them in another. For example, when you transmit an RPC over a tcp link, *ANY* process doing an rpc op, whether related or not, may wind up receiving the response. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message