Date: Thu, 6 Jul 2000 18:43:06 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Marius Bendiksen <mbendiks@eunet.no> Cc: Alfred Perlstein <bright@wintelcom.net>, freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops Message-ID: <200007070143.SAA96248@apollo.backplane.com> References: <Pine.BSF.4.05.10007062327020.68909-100000@login-1.eunet.no>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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
<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?200007070143.SAA96248>