lkml.org 
[lkml]   [2002]   [May]   [9]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateThu, 09 May 2002 11:50:19 -0700
FromAndrew Morton <>
SubjectRe: [PATCH] 2.5.14 IDE 56
Lincoln Dale wrote:
> 
> ...
> i've validated that the performance difference is due to copy_to_user().
> i created a hack in the tree where a read() on a file opened with the
> option O_NOCOPY causes no copy_to_user() to occur. (diff at the bottom of
> this email).
> 
> on this test machine (dual P3 Xeon / 256K L2 cache, 2G PC133 SDRAM, QLogic
> 2300 FC HBA, 8 x 15K RPM disks).
> maximum theoretical performance is 2gbit/s (~200mbyte/sec).  kernel is 2.4.18.
> 
> i get the following performance numbers with 256K reads syncronously from
> the disks:

For bulk read() and write() I/O the best sized buffer is 8 kbytes.  4k is
pretty good, too.  Anything larger blows the user-side buffer out of L1.
This is for x86.

This is a pretty important point, so let's repeat it:

Userspace programmers who are writing bulk-transfer read/write loops
should use an 8 kbyte transfer buffer.

>          /dev/md0 raid-0 with O_DIRECT:          91847kbyte/sec (2781usec
> avg latency/read)
>          /dev/md0 raid-0:                                129455kbyte/sec
> (1978usec avg latency/read)
>          /dev/md0 raid-0 with O_NOCOPY:  195868kbyte/sec (1297usec avg
> latency/read)

hmm.  Why is O_DIRECT always the slowest?  (and it would presumably do
even worse with an 8k transfer size).

-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:26    [from the cache]
©2003-2008