[PATCH] libblock: Add read-ahead task

Chris Johns chrisj at rtems.org
Sat Jun 2 02:30:35 UTC 2012

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.


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


More information about the devel mailing list