Date: Sat, 8 Jul 2000 11:37:28 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Brian Fundakowski Feldman <green@FreeBSD.ORG> Cc: Marius Bendiksen <mbendiks@eunet.no>, Alfred Perlstein <bright@wintelcom.net>, freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops Message-ID: <200007081837.LAA06503@apollo.backplane.com> References: <Pine.BSF.4.21.0007071645250.2603-100000@green.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
:...
: Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
: green@FreeBSD.org `------------------------------'
Let me give you an example, Brian.
Lets say you have a find running on your whole filesystem. The
directories & inodes being scanned by the find are for the most part
not going to be in the cache, which means that find is going to
cause at least two disk I/O's for each small directory and probably
more. So at any given moment, the find process looks like this:
read
low level read I/O dispatched to the disk
(stall)
I/O complete
read
low level read I/O dispatched to the disk
(stall)
I/O complete
read
low level read I/O dispatched to the disk
(stall)
I/O complete
read
low level read I/O dispatched to the disk
(stall)
I/O complete
Now lets say you have some other process -- any other process, which
needs to do disk I/O. It issues a read:
read
(stall waiting for the I/O find has *ALREADY* dispatched to the disk
to complete)
low level read I/O dispatched to the disk
(stall)
I/O complete
You have this problem even on a SCSI system with tagged queueing
because the stall is from the disk itself doing a seek.
Here's the problem: Once you've dispatched the I/O to the disk,
you cannot abort it. At the time the find dispatches its I/O to
the disk, there are NO OTHER PROCESSES trying to do I/O. That is,
whenever some other process tries to do I/O the find will ALREADY
have an I/O queued to disk. This is the natuer of an I/O bound
process. The problem isn't the I/O bound process trying to do I/O
on top of some other process's I/O, the problem is that the other
processes are idle and so when they issue their I/O they will find
the find process *already sitting waiting for its own to complete*.
Thus you have nothing to prioritize (short of aborting the find's
disk op, which you can't do).
Dealing with this problem is not trivial. The only way to deal with
it is to have the kernel actually impose a delay in the dispatch of
find's I/O, even though no other processes are requesting I/O at the
time, in order to give another process the chance to do several I/O's
(non I/O bound I/O's) in between the I/O's that find/cvsup do (each
of which has massive disk overhead due to the seeking). Needless to
say, figuring out what kind of delay to impose is hard.
-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?200007081837.LAA06503>