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

[Daniel Phillips]

On January 21, 2002 05:06 pm, [e-mail] 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