From owner-freebsd-arch Thu Jul 6 18:43:16 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 E15CF37BBC7 for ; Thu, 6 Jul 2000 18:43:11 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA96248; Thu, 6 Jul 2000 18:43:06 -0700 (PDT) (envelope-from dillon) Date: Thu, 6 Jul 2000 18:43:06 -0700 (PDT) From: Matthew Dillon Message-Id: <200007070143.SAA96248@apollo.backplane.com> To: Marius Bendiksen Cc: Alfred Perlstein , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> 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. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message