From owner-freebsd-arch Thu Jul 6 18:49: 8 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 59D7C37BCBF for ; Thu, 6 Jul 2000 18:49:03 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e671mxt27908; Thu, 6 Jul 2000 18:48:59 -0700 (PDT) Date: Thu, 6 Jul 2000 18:48:59 -0700 From: Alfred Perlstein To: Matthew Dillon Cc: Marius Bendiksen , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops Message-ID: <20000706184859.C25571@fw.wintelcom.net> References: <200007070143.SAA96248@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007070143.SAA96248@apollo.backplane.com>; from dillon@apollo.backplane.com on Thu, Jul 06, 2000 at 06:43:06PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Matthew Dillon [000706 18:43] wrote: > :> Can you elaborate on the problem you are describing? I'm not sure > :> I understand besideds certain processes being able to hog the > :> buffercache and filesystems. > : > :The problem lies, as I understand it (ask Feldman for details) in that a > :find(1) or similar process will cause a lot of work to be done in kernel > :space, which means the scheduler is not going to clamp down on it. Also, > :it apparently hogs buffercache and I/O bandwidth. Changing these VOPs to > :be incremental would solve the problem. > : > :Marius > > I don't think it's that at all. Obviously find and cvsup eat a lot > of *DISK* bandwidth -- all from seeking. The actual *I/O* bandwidth > is very low (probably less then 1MByte/sec), but the disk is saturated. > > So I don't think we are blowing up any caches. > > What may be happening here is stalling in namei(). find and cvsup > are very heavy on path lookups and that combined with seek latency > on the drive could result in filesystem locks on directories being > held for much longer periods of time then normal. Any other process > trying to 'open' a file (verses reading or writing an already-open file) > would start to stall. just a note: sysctl -w vfs.vmiodirenable=1 helps a _lot_. :) -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message