[PATCH] libblock: Add read-ahead task

[Sebastian Huber]

On 06/01/2012 01:09 AM, Chris Johns wrote:
> On 31/05/12 7:23 PM, sebastian.huber at embedded-brains.de wrote:
>> From: Sebastian Huber<sebastian.huber at embedded-brains.de>
>>
>> Read-ahead requests were previously executed in the context of the
>> reading task. This blocks the reading task until the complete read
>> with read-ahead transfer is finished. A read-ahead task is introduced
>> to off-load the read-ahead transfer. This allows the reading task to
>> work with the requested block more quickly. The read-ahead is triggered
>> after two misses of ascending consecutive blocks or a read hit of a
>> block read by the most-resent read-ahead transfer.
>
> It is not clear to me the gain this change gives us. Do you have any
> performance related data that shows the improvement this change gives us ?

The gain is that the read-ahead tasks waits for read-ahead data and not the 
main task.  E.g. consider to read a large file from disk and transfer it via 
network.  One DMA reads the data from the disk and another DMA transfers it to 
the network.  With the read-ahead task the disk DMA is triggered mostly 
independent of the main task which copies the data from the file descriptor to 
the socket and performs all the high level file and network operations.  I my 
particular test scenario this change gives a 33% throughput increase.

>
> The ability of the reader to return quickly on a read call is important yet the
> benefit of lowering the overhead to read data is also important. I can see real
> performance gains where the driver is DMA and interrupt driven and SMP would
> also help here.

How do you achieve high performance without DMA and interrupts?

>
> I see a more important issue, the ability of the file system to indicate if
> read-ahead is suitable. In the case of file system meta data management the
> effect of read-ahead is questionable. The same is true for reading for write.
> For reading file data the process is speculative and I wonder if a way to
> increase the read-ahead based on continued non-seek reading is something worth
> looking at. This means read-ahead control being moved from the cache to the
> file system maybe worth considering.

I agree that the current read-ahead system is questionable.  This change is 
only an improvement of the current system.  One slight improvement is the new 
trigger condition: The read-ahead is triggered after two misses of ascending 
consecutive blocks or a read hit of a block read by the most-recent read-ahead 
transfer.

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.