>> Because that's what benchmarks and real production use of some
>> applications with and without direct io show :-)  I don't think "cp"
>> is such a good example though, since you lose the readahead.
> yes it is.  option -D<size> should do copy with direct I/O and given
> buffer size (1MB should be ok for modern disk)

So?  You still lose readahead.  If the disk does readahead (which most
disks do, but not necessarily to the extent you want) and no other I/O
to it happens in between (which may or may not be true), you may avoid
the overhead of seek and rotate, but you'll still pay the penalty of
various bus arbitrations and the data transfer.

For this paradigm, what you really want is a call that says "start
doing this I/O, let me continue to run, and give me some way to, later,
block until it's finished".  Or perhaps "block until one of various
such has finished".

Given that, cp could do the readahead.  But do you really want it to?
I don't see why it should have to.

What you really want is a way to tell the kernel that buffers filled
solely to satisfy this I/O should be aged into oblivion once the I/O
completes, so that they are _first_ to be re-used.  Then something like
cp of a file bigger than RAM doesn't push everything else out.

ISTM that mmap with MADV_SEQUENTIAL and possibly judicious use of
MADV_DONTNEED/MADV_FREE should do the right thing.  You'd still have to
take care to make cp handle files bigger than it can mmap(), but I
don't see it as unreasable to (say) have to do a half-dozen syscalls
for every 64MB copied....

>> For some (typically database-like) apps it can be a pretty big boost
> and: gimp (tempfile), movies, audio editors, everything operating on
> LARGE files

Depends on what it does with them, of course.  And, especially these
days with RAM so cheap, "LARGE" in the here-relevant sense is a lot
larger than it used to be.  (For example, it's not that unusual to find
a machine with enough RAM to hold a whole CD's contents.)

/~\ 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