Re: O_DIRECT on 2.4.19pre8aa2 md device

[Lincoln Dale]

At 05:51 PM 21/05/2002 +0200, Andrea Arcangeli wrote:
...
>In any real usage where I/O is combined with CPU and mem bus utilization
>for computations, not only to move data from disk to userspace memory
>O_DIRECT is an _huge_ win as you found out. You have 100000 more usable
>ticks for computations over 150000 total ticks.
...

no disagreement there.

however, there is still an enormous difference between 
access-/dev/sdX-via-block-layer and access-dev/sdX-via-mmap (127mbyte/sec 
versus 175+mbyte/sec) that for many "disk intensive" applications is a huge 
difference.

if we _could_ produce superior performance with something like:
  (a) additional improvements to O_DIRECT (say, a mmap() hack for O_DIRECT)
      whereby i/o can go direct-to-userspace or 
userspace-can-mmap(readonly)-into-
      kernel-space
or
  (b) O_DIRECT with async-i/o
or
  (c) /dev/rawN-like interface (eg. /dev/directN) within a fixed disk 
buffer in kernel
      (eg. physical memory allocated at bootup) that is populated readonly into
      user-space)
would such a hack be accepted in the 2.5 tree?

it sure isn't your "average desktop" setup where you hit these things as 
performance limitations, but many folk (myself included) have very specific 
applications which are essentially bottlenecked on PC hardware 
limitations.  these limitations are a side-effect of how the linux kernel 
works.
that doesn't mean that other OSes don't suffer from the same thing -- since 
no-other mainstream OS does the right thing, that doesn't mean that we 
cannot make linux even better.

obviously, many of the above would only be suitable for disk-read 
operations and less-so for disk-write -- but its probably easier to tackle 
these one by one.

cheers,

lincoln.