[PATCH] libblock: Add read-ahead task

[Chris Johns]

On 1/06/12 4:51 PM, Sebastian Huber wrote:
> 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.

This is a nice increase in performance. Adding the task in the cache is 
much preferred over a driver async interface.

>
>>
>> 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?
>

No questioning this from me. Good hardware and system design is needed 
to get high performance. The current ATA driver is polled and this is a 
blot on RTEMS. I hope the TCP stack work and the BSD frame work will 
allow a SATA driver framework to come into RTEMS.

>>
>> 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.

Ok.

> 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.

I see the read value of 0 disables read-ahead which is good. I assume 
this means the read-ahead task is not created. Does this mean any other 
value creates the task ?

Chris