From: Suparna Bhattacharya <suparna@in.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Badari Pulavarty <pbadari@us.ibm.com>,
linux-kernel@vger.kernel.org, linux-aio@kvack.org
Subject: Re: [PATCH][2.6-mm] Readahead issues and AIO read speedup
Date: Fri, 8 Aug 2003 19:26:45 +0530 [thread overview]
Message-ID: <20030808135645.GA3430@in.ibm.com> (raw)
In-Reply-To: <20030807135819.3368ee16.akpm@osdl.org>
On Thu, Aug 07, 2003 at 01:58:19PM -0700, Andrew Morton wrote:
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
> >
> > On Thursday 07 August 2003 10:39 am, Andrew Morton wrote:
> > > Badari Pulavarty <pbadari@us.ibm.com> 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@in.ibm.com)
Linux Technology Center
IBM Software Labs, India
next prev parent reply other threads:[~2003-08-08 13:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-07 10:01 [PATCH][2.6-mm] Readahead issues and AIO read speedup Suparna Bhattacharya
2003-08-07 16:01 ` Badari Pulavarty
2003-08-07 16:28 ` Andrew Morton
2003-08-07 17:21 ` Badari Pulavarty
2003-08-07 17:39 ` Andrew Morton
2003-08-07 20:41 ` Badari Pulavarty
2003-08-07 20:58 ` Andrew Morton
2003-08-08 13:56 ` Suparna Bhattacharya [this message]
2003-08-13 21:06 ` Ram Pai
2003-09-23 0:41 ` Ram Pai
2003-08-07 19:36 ` Joel Becker
2003-08-08 5:42 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030808135645.GA3430@in.ibm.com \
--to=suparna@in.ibm.com \
--cc=akpm@osdl.org \
--cc=linux-aio@kvack.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbadari@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox