>> As Thor (I think it was) pointed out, going out to disk - even if
>> you hit the disk's cache - is significantly slower than finding the
>> data already in host RAM.
> so it will be little slower as ONE process.
> but making lower load which is more important on multiuser system.

Depends on what the rest of the system is doing.  If it's memory or
compute bound, perhaps.  If not, taking bus resources for a disk
transfer, forcing the disk to seek away from what it was doing to your
data, may be more intrusive than the memcpy.  It All Depends.

>>> or/and large blocks it's no difference.
>> I don't see what difference the block size makes.  Could you
>> explain?
> when blocksize>>readahead size.

Oh!  Yes, if you don't read ahead enough, readahead borders on useless.
That's always true of any readahead.

>>>> (Unless the application provides such a place, which we agreed it
>>>> shouldn't need to do.)
>>> application can use O_ASYNC
>> How does that help?
> you do this way:
> request_read_first_block_and_wait
> request_read_second_block
> process_first block
> wait_for_second_block_read
> request_read_third_block
> process_second_block
> wait_for_third_block_read
> request_read_fourth_block
> process_third....

But I thought we agreed that the application shouldn't have to do its
own readahead, which is exactly what this is doing.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B