Re: [PATCH][2.6-mm] Readahead issues and AIO read speedup

[Suparna Bhattacharya]

On Thu, Aug 07, 2003 at 01:58:19PM -0700, Andrew Morton wrote:
> Badari Pulavarty <pbadari@xxxxxxxxxx> wrote:
> >
> > On Thursday 07 August 2003 10:39 am, Andrew Morton wrote:
> >  > Badari Pulavarty <pbadari@xxxxxxxxxx> wrote:
> >  > > We should do readahead of actual pages required by the current
> >  > > read would be correct solution. (like Suparna suggested).
> >  >
> >  > I repeat: what will be the effect of this if all those pages are already in
> >  > pagecache?
> > 
> >  Hmm !! Do you think just peeking at pagecache and bailing out if
> >  nothing needed to be done, is too expensive ? Anyway, slow read
> >  code has to do this later. Doing it in readahead one more time causes
> >  significant perf. hit ?
> 
> It has been observed, yes.
> 
> > And also, do you think this is the most common case ?
> 
> It is a very common case.  It's one we need to care for.  Especially when
> lots of CPUs are hitting the same file.

So, you are concerned about the case when the window was maximally
shrunk via check_ra_success because the pages are already cached ?
Is it mainly for small reads that the performance hit due to the 
extra pagecache lookup is significant compared to the cycles spent 
in copy_to_user ? For less than page-sized reads clustering isn't
relevant, we can just keep the old behaviour there.

If on the other hand large cached reads are affected as well, then
we need to work on a solution.

> 
> There are things we can do to tweak it up, such as adding a max_index to
> find_get_pages(), then do multipage lookups, etc.  But not doing it at all
> is always the fastest way.

Regards
Suparna

-- 
Suparna Bhattacharya (suparna@xxxxxxxxxx)
Linux Technology Center
IBM Software Labs, India

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