Date: Fri, 7 Jul 2000 16:55:55 -0400 (EDT) From: Brian Fundakowski Feldman <green@FreeBSD.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Marius Bendiksen <mbendiks@eunet.no>, Alfred Perlstein <bright@wintelcom.net>, freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops Message-ID: <Pine.BSF.4.21.0007071645250.2603-100000@green.dyndns.org> In-Reply-To: <200007070143.SAA96248@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 6 Jul 2000, Matthew Dillon 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. Right, that is definitely true. It's the disk bandwidth, not the cache. > 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. No, that's not it. This is all about reading and writing, not lookups. The computer is slow with regard to I/O, not namei operations. We do not have any kind of disk scheduler to prioritize I/O, and some operations are extremely harsh on bandwidth, most notably reading directories. I don't know about you, but my home directory takes about 3 or 4 seconds of churning before an ls -l spits out the contents; during this time, other processes reading and writing get stalled very easily. If I were to be burning a CD, this likely would have caused an underrun. I do not have a set of extremely slow disks, nor is there contention on the bus. Each disk (and the CD-ROM drive) is ATA, but has its own controller: ad0: 6103MB <ST36422A> [13228/15/63] at ata0-master using UDMA33 ad1: 9671MB <WDC AC310100B> [19650/16/63] at ata1-master using UDMA33 ad2: 1554MB <Maxtor 71626 AP> [3158/16/63] at ata2-master using WDMA2 acd0: CD-R <\^B 1.10 CR-2801TE> at ata3-master using PIO0 Directory operations have extremely detrimental effects on overall system performance. They definitely seem to take overall priority. > -Matt > Matthew Dillon > <dillon@backplane.com> -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' 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?Pine.BSF.4.21.0007071645250.2603-100000>