From: WU Fengguang <wfg@mail.ustc.edu.cn>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fadvise invalidating range fix
Date: Tue, 9 Mar 2004 19:28:25 +0800 [thread overview]
Message-ID: <20040309112825.GA4150@mail.ustc.edu.cn> (raw)
In-Reply-To: <20040308120322.118a640b.akpm@osdl.org>
On Mon, Mar 08, 2004 at 12:03:22PM -0800, Andrew Morton wrote:
> WU Fengguang <wfg@mail.ustc.edu.cn> wrote:
> >
> >
> > - When 'offset' and/or 'offset+len' do no align to page boundary, we must
> > decide whether to abandon the partial page at the beginning/end of the range.
> > My patch assumes that the application is scanning forward,
> > which is the most common case.
> > So 'end_index' is set to the page just before the ending partial page.
>
> If you're going to preserve the partial page at `end' (which seems
> reasonable) then you should also preserve the partial page at `start', don't
> you agree?
>
> - start_index = offset >> PAGE_CACHE_SHIFT;
> + start_index = (offset + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
>
In fact, it depends on the access pattern.
I would expect the normal usage of fadvise to be:
for() {
read() and consume() data in [offset, offset+LEN);
fadvise(fd, offset, LEN, POSIX_FADV_DONTNEED);
offset += LEN; /*scanning forward*/
}
In this case, the partial page at `start' should be freed.
Certainly there may be other patterns.
I wonder the best solution in kernel is to code in favor of the normal case,
and the best(safe and portable) practice in usermode code is to always align
'offset' and 'offset+len' to page boundaries.
And some comment in the manual page of posix_fadvise is recommended.
next parent reply other threads:[~2004-03-09 11:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20040308130754.GA5204@mail.ustc.edu.cn>
[not found] ` <20040308120322.118a640b.akpm@osdl.org>
2004-03-09 11:28 ` WU Fengguang [this message]
2004-03-10 11:11 ` WU Fengguang
2004-03-08 13:06 WU Fengguang
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=20040309112825.GA4150@mail.ustc.edu.cn \
--to=wfg@mail.ustc.edu.cn \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
/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®