Re: [patch 6/12] hold atomic kmaps across generic_file_read

[Andrew Morton]

Linus Torvalds wrote:
> 
> On Sun, 11 Aug 2002, Andrew Morton wrote:
> >
> > At least that's the theory, and the testing I did yesterday
> > was succesful.
> 
> Did you try Simons test-case which seemed to be just a "cat" on a floppy
> 
>   "To demonstrate the problem reliably, I've used "strace -r cat" on a
>    floppy, which is a sufficiently slow medium. :)  This is on a 2.4.19
>    kernel, but 2.5 behaves similarly.")
> 
> although that may be different from the NFS issue, it is kind of
> interesting: the perfect behaviour would be a steady stream of data, not
> too many hickups.

I did, but I cut you from the Cc...

> I happen to have a little test app for this stuff:
> http://www.zip.com.au/~akpm/linux/stream.tar.gz
> 
> You can use it to slowly read or write a file.
> 
>         ./stream -i /dev/fd0h1440 23 1000
> 
> will read 1000k from floppy at 23k per second.  It's a bit
> useless at those rates on 2.4 because of the coarse timer
> resolution.  But in 1000Hz 2.5 it works a treat.
> 
> ./stream -i /dev/fd0h1440 20 1000  0.00s user 0.01s system 0% cpu 51.896 total
> ./stream -i /dev/fd0h1440 21 1000  0.00s user 0.02s system 0% cpu 49.825 total
> ./stream -i /dev/fd0h1440 22 1000  0.00s user 0.02s system 0% cpu 47.843 total
> ./stream -i /dev/fd0h1440 23 1000  0.00s user 0.01s system 0% cpu 45.853 total
> ./stream -i /dev/fd0h1440 24 1000  0.01s user 0.02s system 0% cpu 44.077 total
> ./stream -i /dev/fd0h1440 25 1000  0.00s user 0.02s system 0% cpu 42.307 total
> ./stream -i /dev/fd0h1440 26 1000  0.00s user 0.01s system 0% cpu 41.305 total
> ./stream -i /dev/fd0h1440 27 1000  0.00s user 0.02s system 0% cpu 40.493 total
> ./stream -i /dev/fd0h1440 28 1000  0.01s user 0.02s system 0% cpu 39.122 total
> ./stream -i /dev/fd0h1440 29 1000  0.00s user 0.01s system 0% cpu 39.118 total
> 
> What we see here is perfect readahead behaviour.  The kernel is keeping the
> read streaming ahead of the application's read cursor all the way out to the
> point where the device is saturated. (The numbers are all off by three
> seconds because of the initial spinup delay).
> 
> If you strace it, the reads are smooth on 2.4 and 2.5.
> 
> So it may be an NFS peculiarity.  That's a bit hard for me to test over
> 100bT.

The strace of that app is smooth, all the way out to the peak disk
bandwidth.

So something is different either in the test or in Simon's setup.  It
needs further investigation.