Paul wrote:
>
> ...
> I just thought I would toss this in: For some classes
> of users, latency is extremely critical.
There are several types of latency: interrupt, scheduling, IO, probably
more.
The ones we're most interested in are scheduling latency and IO
latency.
These are two utterly, completely, wildly different things! They differ
by two or three orders of magnitude and their underlying causes and
effects are quite different.
Let's please be careful in making the distinction between the two.
scheduling latency is pretty specialised. You have to push the
system pretty hard to experience a scheduling stall which is longer
than a monitor refresh interval. I don't believe that scheduling latency
is perceptible in desktop use. Audio, yes. Games, maybe.
IO latency is a much larger problem in Linux. Once you start pushing the
system it pops up all over the place. One simple test I use to quantify
this is:
- boot with mem=512m
- perform a continuous appending write to an ext2 file on a scratch
disk.
- Now see how long it takes to build a kernel on a different disk.
This is not a completely silly scenario, and we have problems. I have
one (dopey, hate it) patch which reduces that kernel build time by 30%.
The problem is that `gcc' is being forced to write back data to that
scratch disk within the page allocator. It will take some algorithmic
rework in the VM to fix this properly.
Another prominent source of latency is at the disk request layer, where
heavy writers starve readers. There's a hack^Wfix in Alan's kernels
for this, but nobody has discussed in in a while and I'm not sure how
useful it is being.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 07 2002 - 22:00:15 EST