From: Andrew Morton <akpm@zip.com.au>
To: trond.myklebust@fys.uio.no
Cc: Chuck Lever <cel@citi.umich.edu>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: invalidate_inode_pages in 2.5.32/3
Date: Thu, 05 Sep 2002 18:08:55 -0700 [thread overview]
Message-ID: <3D780027.13A5B3B@zip.com.au> (raw)
In-Reply-To: 15735.64356.246705.392224@charged.uio.no
Trond Myklebust wrote:
>
> >>>>> " " == Andrew Morton <akpm@zip.com.au> writes:
>
> > I'm not sure what semantics we really want for this. If we
> > were to "invalidate" a mapped page then it would become
> > anonymous, which makes some sense.
>
> > But if we want to keep the current "don't detach mapped pages
> > from pagecache" semantics then we should test page->pte.direct
> > rather than page_count(page). Making that 100% reliable would
> > be tricky because of the need for locking wrt concurrent page
> > faults.
>
> I believe that Linus is very much in favour of this latter
> approach. We had the 'anonymize page' semantics under 2.2.x, but they
> were changed in the 2.4.0-pre series.
hm.
> The problem is that NFS can clear your page cache at any
> moment. Things like out-of-order RPC calls etc. can trigger it. If
> your knee-jerk response is to anonymize all those pages that are
> referenced, you might end up with page aliasing (well - in practice
> not, since we do protect against that but Linus wasn't convinced).
Oh. I thought this was a "purely theoretical" discussion because
it only pertains to directory data. You seem to be saying that
NFS is doing this for S_ISREG pagecache also?
Again: what do you _want_ to do? Having potentially incorrect pagecache
mapped into process memory space is probably not the answer to that ;)
Should we be forcibly unmapping the pages from pagetables? That would
result in them being faulted in again, and re-read.
> > The mapping's releasepage must try to clear away whatever is
> > held at ->private. If that was successful then releasepage()
> > must clear PG_private, decrement
> > page-> count and return non-zero. If the info at ->private is not
> > freeable, releasepage returns zero. ->releasepage() may not
> > sleep in
> > 2.5.
>
> Interesting. Our 'private data' in this case would be whether or not
> there is some pending I/O operation on the page. We don't keep it in
> page->private, but I assume that's less of a problem ;-)
> It's unrelated to the topic we're discussing, but having looked at it
> I was thinking that we might want to use it in order to replace the
> NFS 'flushd' daemon. Currently the latter is needed mainly in order
> to ensure that readaheads actually do complete in a timely fashion
> (i.e. before we run out of memory). Since try_to_release_page() is
> called in shrink_cache(), I was thinking that we might pass that buck
> on to releasepage()
That might work. It's a bit of a hassle that ->releasepage() must
be nonblocking, but generally it just wants to grab locks, decrement
refcounts and free things.
> (btw: there's currently a bug w.r.t. that'. If I understand you
> correctly, the releasepage() thing is unrelated to page->buffers, but
> the call in shrink_cache() is masked by an 'if (page->buffers))
That would be in a 2.4 kernel? In 2.4, page->buffers can only
contain buffers. If it contains anything else the kernel will
die.
> Extending that idea, we might also be able to get rid of
> nfs_try_to_free_pages(), if we also make releasepage() call the
> necessary routines to flush dirty pages too...
->releasepage() should never succeed against a dirty page. In fact
the VM shouldn't even bother calling it - there's a minor efficiency
bug there.
If your mapping has old, dirty pages then the VM will call your
->vm_writeback to write some of them back. Or it will repeatedly
call ->writepage if you don't define ->vm_writeback. That's the
place to clean the pages.
next prev parent reply other threads:[~2002-09-06 1:06 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-05 14:25 invalidate_inode_pages in 2.5.32/3 Chuck Lever
2002-09-05 18:27 ` Andrew Morton
2002-09-05 18:53 ` Chuck Lever
2002-09-05 19:17 ` Andrew Morton
2002-09-05 20:00 ` Trond Myklebust
2002-09-05 20:15 ` Andrew Morton
2002-09-05 20:27 ` Trond Myklebust
2002-09-05 20:37 ` Andrew Morton
2002-09-05 20:51 ` Trond Myklebust
2002-09-05 21:12 ` Andrew Morton
2002-09-05 21:31 ` Trond Myklebust
2002-09-05 22:19 ` Andrew Morton
2002-09-06 0:48 ` Trond Myklebust
2002-09-06 1:08 ` Andrew Morton [this message]
2002-09-06 6:49 ` Trond Myklebust
2002-09-07 8:37 ` Daniel Phillips
2002-09-07 16:09 ` Andrew Morton
2002-09-07 17:02 ` Andrew Morton
2002-09-07 8:24 ` Daniel Phillips
2002-09-07 16:06 ` Andrew Morton
2002-09-09 21:08 ` Daniel Phillips
2002-09-09 21:36 ` Andrew Morton
2002-09-09 22:12 ` Daniel Phillips
2002-09-07 18:47 ` Rik van Riel
2002-09-07 23:09 ` Andrew Morton
2002-09-09 21:44 ` Daniel Phillips
2002-09-09 22:03 ` Andrew Morton
2002-09-09 22:19 ` Daniel Phillips
2002-09-09 22:32 ` Andrew Morton
2002-09-10 16:57 ` Daniel Phillips
2002-09-09 23:51 ` Chuck Lever
2002-09-10 1:07 ` Daniel Phillips
2002-09-10 15:09 ` Chuck Lever
2002-09-10 16:13 ` Daniel Phillips
2002-09-10 19:04 ` Chuck Lever
2002-09-10 20:52 ` Daniel Phillips
2002-09-11 0:07 ` Andrew Morton
2002-09-11 0:27 ` Daniel Phillips
2002-09-11 0:38 ` Andrew Morton
2002-09-11 0:53 ` Daniel Phillips
2002-09-11 1:49 ` Andrew Morton
2002-09-11 2:14 ` Daniel Phillips
2002-09-11 16:18 ` Rik van Riel
2002-09-11 17:14 ` Daniel Phillips
2002-09-12 19:06 ` Daniel Phillips
2002-09-12 22:05 ` Urban Widmark
2002-09-12 22:21 ` Andrew Morton
2002-09-12 22:30 ` Rik van Riel
2002-09-12 22:43 ` Daniel Phillips
2002-09-12 22:51 ` Andrew Morton
2002-09-12 23:05 ` Randy.Dunlap
2002-09-12 23:23 ` Rik van Riel
2002-09-12 23:53 ` Daniel Phillips
2002-09-23 16:38 ` Trond Myklebust
2002-09-23 17:16 ` Daniel Phillips
2002-09-23 18:57 ` Andrew Morton
2002-09-23 20:41 ` Trond Myklebust
2002-09-23 20:49 ` Daniel Phillips
2002-09-23 22:43 ` Trond Myklebust
2002-09-24 5:09 ` Daniel Phillips
2002-09-24 16:40 ` Trond Myklebust
2002-09-23 19:13 ` Daniel Phillips
2002-09-13 4:19 ` Daniel Phillips
2002-09-13 4:52 ` Daniel Phillips
2002-09-14 9:58 ` Urban Widmark
2002-09-12 13:04 ` Trond Myklebust
2002-09-12 18:21 ` Andrew Morton
2002-09-12 21:15 ` Daniel Phillips
2002-09-12 21:38 ` Andrew Morton
2002-09-12 21:52 ` Daniel Phillips
2002-09-05 22:01 ` Chuck Lever
2002-09-05 22:23 ` Andrew Morton
2002-09-05 21:41 ` Chuck Lever
2002-09-06 9:35 ` Helge Hafting
2002-09-06 16:16 ` Chuck Lever
2002-09-07 8:01 ` Daniel Phillips
2002-09-07 10:01 ` Daniel Phillips
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=3D780027.13A5B3B@zip.com.au \
--to=akpm@zip.com.au \
--cc=cel@citi.umich.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
/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;
as well as URLs for NNTP newsgroup(s).