From owner-freebsd-arch Fri Jul 7 13:56: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id D390137BC42; Fri, 7 Jul 2000 13:55:57 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Fri, 7 Jul 2000 16:55:55 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Matthew Dillon Cc: Marius Bendiksen , Alfred Perlstein , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops In-Reply-To: <200007070143.SAA96248@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 [13228/15/63] at ata0-master using UDMA33 ad1: 9671MB [19650/16/63] at ata1-master using UDMA33 ad2: 1554MB [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 > -- 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