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

[Andrew Morton <akpm@zip.com.au>]

Simon Kirby wrote:
> 
> On Sun, Aug 11, 2002 at 08:28:12PM -0700, Andrew Morton wrote:
> 
> > So I'd appreciate it if Simon could invetigate a little further
> > with the test app I posted.  Something is up, and it may not
> > be just an NFS thing.  But note that nfs_readpage will go
> > synchronous if rsize is less than PAGE_CACHE_SIZE, so it has
> > to be set up right.
> 
> You're right -- my NFS page size is set to 2048.  I can't remember if I
> did this because I was trying to work around huge read-ahead or because I
> was trying to work around the bursts of high latency from my Terayon
> cable modem (which idles at a slow line speed and "falls forward" to
> higher speeds once it detects traffic, but with a delay, causing awful
> latency at the expense of "better noise immunity").  Anyway, I will test
> this tomorrow.  I recall that 1024 byte-sized blocks were too small
> because the latency of the cable modem would cause it to not have high
> enough throughput, so I settled with 2048.

OK, thanks.

> I haven't been able to test your application over NFS yet, but I did get
> a chance to test it with a floppy.  I was able to (on 2.4.19) reproduce a
> case where even with just 5 KB/second reads, the read() would block every
> so often (long strace attached).

Well with a 64k readahead chunk the kernel will only talk to the
floppy drive once per 13 seconds.  Surely it's spinning down?
Try setting the readahead to 16 kbytes (three seconds) with

	blockdev --setra 32 /dev/floppy
 
> 
> So, something does appear to be wrong.  If I can actually mount a
> filesystem on a floppy in 2.5, I'll see if the same thing happens.

Nope, floppy is bust.  But you can read directly from /dev/fd0h1440 OK.