Re: [2.4.17/18pre] VM and swap - it's really unusable

Daniel Phillips (phillips@bonn-fries.net)
Mon, 21 Jan 2002 17:48:30 +0100


On January 21, 2002 05:06 pm, yodaiken@fsmlabs.com wrote:
> On Mon, Jan 21, 2002 at 05:05:01PM +0100, Daniel Phillips wrote:
> > > I think of "benefit", perhaps naiively, in terms of something that can
> > > be measured or demonstrated rather than just announced.
> >
> > But you see why asap scheduling improves latency/throughput *in theory*,
>
> Nope. And I don't even see a relationship between preemption and asap I/O
> schedulding. What make you think that I/O threads won't be preempted by
> other threads?

Consider a thread reading from disk in such a way that readahead is no help,
i.e., perhaps the disk is fragmented. At each step the IO thread schedules a
read and sleeps until the read completes, then schedules the next one. At
the same time there is a hog in the kernel, or perhaps there is
competition from other tasks using the kernel. In any event, it will
frequently transpire that at the time the disk IO completes there is somebody
in the kernel. Without preemption the IO thread has to wait until the kernel
hog blocks, hits a scheduling point or exits the kernel.

The result, without preemption, is:

IO thread Kernel hog Disk
| .
|--------------.-----------> .
. | |
. | |
. | |
. | |
. |<------------|
. | .
. | .
. | .
.<-------------| .
|--------------.-----------> .
. . |
. . |
. | |
. | |
. | |
. |<------------|
. | .
. | .
. | .
.<-------------| .
|--------------.-----------> .
. . |
. . |
. | |
. | |
. | |
. |<------------|
. | .
. | .
. | .
.<-------------| .
.

Whereas with preemption, we have:

IO thread Kernel hog Disk
| .
|--------------.-----------> .
. | |
. | |
. | |
. | |
.<-------------|-------------|
|--------------.-----------> .
. | |
. | |
. | |
. | |
.<-------------|-------------|
|--------------.-----------> .
. | |
. | |
. | |
. | |
.<-------------|-------------|
|

The disk and the IO thread are active a higher portion of the time, while the
kernel hog gets the same amount of time. So in this case we have improved
both latency and throughput.

Naturally I constructed this case to show the effect most clearly. There are
many possible variations on the above scenario. It does seem to explain the
latency/throughput improvements that have been reported in practice.

--
Daniel
-
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/