Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 May 2000 09:26:37 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Chuck Paterson <cp@bsdi.com>
Cc:        Andrew Gallatin <gallatin@cs.duke.edu>, arch@FreeBSD.ORG
Subject:   Re: Short summary 
Message-ID:  <200005251626.JAA82954@apollo.backplane.com>
References:   <200005251502.JAA24170@berserker.bsdi.com>

next in thread | previous in thread | raw e-mail | index | archive | help
:}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 
					<dillon@backplane.com>


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005251626.JAA82954>