Re: elevator-starvation-4 (2.2.14 && 2.3.42)

From: Matthew Kirkwood (weejock@ferret.lmh.ox.ac.uk)
Date: Fri Feb 11 2000 - 03:40:12 EST


On Thu, 10 Feb 2000, Bruce Thompson wrote:

> Sorry, but I must respectfully disagree. The time to service the
> request specifically is _not_ unbounded, it's bounded by the size
> of the disk.

Bounded by the size of a 100Gb disk array means bounded by several
hours. I don't want to have to wait several hours for ps to read
in /etc/passwd so I can kill whatever process went nuts.

> In general I would assert that the probability of the user process
> swamping the driver in this manner is extremely low, or else the
> relative priority between the driver and the user process is mixed
> up.

It happens on reiserfs. Try it.

And if my disk bus/disk/driver can write X Mb per second, and I have a
single process which wants to write X Mb per second then, filesystem
permitting, I don't want my task to get stuck writing (X/2) Mb / sec,
just because some silly heuristic said that it didn't deserve it.

> I would further argue that before sending the block up to the user
> process you really ought to kick-off servicing block 11 since that's
> going to take a long time and the user process should be able to
> proceed in the mean time.

My example was very simplistic. Think how "cp /dev/zero ." works:

Read block from /dev/zero
Write block to ./zero
Repeat

Unless you have very slow CPUs, you will fill up RAM with dirty pages/
buffers eventually. That will cause the write to stall while the kernel
pushes out dirty pages to disk. Once the first lot of IOs have completed
and a few others have been scheduled, the cp wakes up, finishes its write
and gets on with filling your disk.

Now, depending upon your filesystems alloction strategies, it's entirely
possible completely to starve a process waiting for a teeny-tiny IO at
the other end of the disk (or at the same end, but you're moving away
from it).

Really, it happens. You don't see it so mcuh with SCSI, but it happens
a lot with IDE.

Matthew.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:19 EST