Re: [PATCH] 2.4 read ahead never reads the last page in a file

From: Marcelo Tosatti
Date: Fri Dec 05 2003 - 11:36:08 EST




On Fri, 5 Dec 2003, Andrea Arcangeli wrote:

> On Wed, Dec 03, 2003 at 06:10:31PM -0500, Chuck Lever wrote:
> > hi marcelo-
> >
> > i posted this a while back on fsdevel for comments, but never heard
> > anything. i'd like this patch to be included in 2.4.24, as it improves
> > NFS client read performance by a significant margin, and doesn't appear to
> > have any negative impact (see fsdevel archives for benchmarks). this is
> > against 2.4.23.
> >
> > generic_file_readahead never reads the last page of a file. this means
> > the last page is always read synchronously by do_generic_file_read.
> > normally this is not an issue, as most local disk reads are fast.
>
> sending two sync req is quite slower than 1 sync req even with the disk,
> infact in my experience the biggest issue with fast storage isn't the
> seeking but the need of sending big requests down to the hardware.
> Infact I think it's a _much_ bigger issue for disk than for nfs. Can you
> benchmark it on a IDE with 128k long files? They should be read with a
> single command, two commands are going to hurt.
>
> > diff -X /home/cel/src/linux/dont-diff -Naurp 00-stock/mm/filemap.c 01-readahead1/mm/filemap.c
> > --- 00-stock/mm/filemap.c 2003-11-28 13:26:21.000000000 -0500
> > +++ 01-readahead1/mm/filemap.c 2003-12-03 16:46:11.000000000 -0500
> > @@ -1299,11 +1299,14 @@ static void generic_file_readahead(int r
> > */
> > ahead = 0;
> > while (ahead < max_ahead) {
> > - ahead ++;
> > - if ((raend + ahead) >= end_index)
> > + unsigned long ra_index = raend + ahead + 1;
> > +
> > + if (ra_index > end_index)
> > break;
> > - if (page_cache_read(filp, raend + ahead) < 0)
> > + if (page_cache_read(filp, ra_index) < 0)
> > break;
> > +
> > + ahead++;
> > }
> > /*
> > * If we tried to read ahead some pages,
> >
>
> looks ok to me. I guess this could be an historic paranoid/(possibly
> needed in the past) thing, to avoid reading partial pages from there,
> but the pagecache layer is robust enough to handle it these days.

Patch applied.



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