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

[Trond Myklebust <trond.myklebust@fys.uio.no>]

>>>>> " " == Andrew Morton <akpm@zip.com.au> writes:

     > 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.

Sorry if somebody already covered this (I'm still a bit jetlagged so I
may have missed part of the argument) but if the read is synchronous,
why should we care about doing readahead at all?

Wasn't the 2.4.x code designed so that you first scheduled the read
for the page you are interested in, and only if the page was not
immediately made available would you then schedule some readahead?

Cheers,
  Trond