From: Jan Kara <jack@suse.cz>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, npiggin@suse.de
Subject: Re: [PATCH] Improve heuristic detecting sequential reads
Date: Wed, 11 Apr 2007 14:17:03 +0200 [thread overview]
Message-ID: <20070411121703.GA3769@duck.suse.cz> (raw)
In-Reply-To: <20070410192722.9e6efc8b.akpm@linux-foundation.org>
On Tue 10-04-07 19:27:22, Andrew Morton wrote:
> On Tue, 10 Apr 2007 17:54:11 +0200 Jan Kara <jack@suse.cz> wrote:
>
> > Introduce ra.offset and store in it an offset where the previous read ended. This way
> > we can detect whether reads are really sequential (and thus we should not mark the page
> > as accessed repeatedly) or whether they are random and just happen to be in the same page
> > (and the page should really be marked accessed again).
>
> (less columns, please)
Oops, sorry.
> OK. So prev_page and prev_offset are now a complexified representation of a
> loff_t, no?
Yes.
> So why don't we just use a loff_t for this?
I did not merge them because most other things in file_ra_state are in
pages and thus comparisons and assignments would require additional
shifts, which would IMHO make the whole thing less clear.
> Anyway, the asymmetry in our handling of prev_index (sometimes called
> prev_page!) and prev_offset is unpleasing. This:
prev_page is a member of the file_ra_state. Probably prev_index would be
better name there...
> --- a/mm/filemap.c~readahead-improve-heuristic-detecting-sequential-reads-tidy
> +++ a/mm/filemap.c
> @@ -933,6 +933,7 @@ page_ok:
> if (prev_index != index || offset != prev_offset)
> mark_page_accessed(page);
> prev_index = index;
> + prev_offset = ra.offset = offset;
>
> /*
> * Ok, we have the page, and it's up-to-date, so
> @@ -948,7 +949,6 @@ page_ok:
> offset += ret;
> index += offset >> PAGE_CACHE_SHIFT;
> offset &= ~PAGE_CACHE_MASK;
> - prev_offset = ra.offset = offset;
>
> page_cache_release(page);
> if (ret == nr && desc->count)
>
> improves things somewhat. But I think it would be nicer if their handling
> was unified, or at least consistent. We update ra.offset here, and we
> update ra.prev_page over there.
It's clearer but wrong, as Wu already noted :). But the assignment
prev_index = index
can be shifted somewhat lower (definitely after the comment) which makes
things slightly more readable.
> And shouldn't offset be called prev_offset? Or should prev_page be called
> page? Or index? Or prev_index? Or Marmaduke? The naming is all a mess.
I vote for prev_index and 'offset' could be prev_offset. I'll create a
tidy-up patch...
Honza
--
Jan Kara <jack@suse.cz>
SuSE CR Labs
next prev parent reply other threads:[~2007-04-11 12:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-10 15:54 Jan Kara
2007-04-10 22:56 ` Andi Kleen
2007-04-10 23:45 ` Andrew Morton
[not found] ` <20070411035448.GA4724@mail.ustc.edu.cn>
2007-04-11 3:54 ` WU Fengguang
2007-04-11 10:20 ` Andi Kleen
2007-04-11 2:27 ` Andrew Morton
2007-04-11 12:17 ` Jan Kara [this message]
2007-04-12 15:57 ` Jan Kara
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=20070411121703.GA3769@duck.suse.cz \
--to=jack@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
/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
all inboxes | Powered by JetHome®