From: Jan Kara <jack@suse.cz>
To: Trond Myklebust <trondmy@primarydata.com>
Cc: "jack@suse.cz" <jack@suse.cz>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"anna.schumaker@netapp.com" <anna.schumaker@netapp.com>
Subject: Re: Why is NFS using a_ops->freepage?
Date: Thu, 5 Oct 2017 16:50:27 +0200 [thread overview]
Message-ID: <20171005145027.GA31299@quack2.suse.cz> (raw)
In-Reply-To: <1507210761.20822.2.camel@primarydata.com>
On Thu 05-10-17 13:39:23, Trond Myklebust wrote:
> Hi Jan,
>
> On Thu, 2017-10-05 at 10:36 +0200, Jan Kara wrote:
> > Hello,
> >
> > I'm doing some work in page cache handling and I have noticed that
> > NFS is
> > the only user of mapping->a_ops->freepage callback. From a quick look
> > I
> > don't see why isn't NFS using ->releasepage / ->invalidatepage
> > callback as
> > all other filesystems do? I agree you would have to set PagePrivate
> > bit for
> > those to get called for the directory mapping however that would seem
> > like
> > a cleaner thing to do anyway - in fact you do have private data in
> > the
> > page. Just they are not pointed to by page->private but instead are
> > stored
> > as page data... Am I missing something?
> >
> > Honza
>
> I'm not understanding your point. delete_from_page_cache() doesn't call
> releasepage AFAICS.
No, but before getting to delete_from_page_cache() the filesystem is
guaranteed to get either ->invalidatepage or ->releasepage callback called
(if it defines them). And at that point the page is already locked and on
its way to be destroyed. So my point was you could use these callbacks
instead to achieve the same...
If you are afraid of races, I don't think those can happen for NFS. Page
can be destroyed either because of truncate - at that point there's no risk
of anyone else looking at that page for directories (i_rwsem) - or because
of page reclaim - at which point we are guaranteed nobody else holds a
reference to the page and new reference cannot be acquired.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2017-10-05 14:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-05 8:36 Why is NFS using a_ops->freepage? Jan Kara
2017-10-05 13:39 ` Trond Myklebust
2017-10-05 14:50 ` Jan Kara [this message]
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=20171005145027.GA31299@quack2.suse.cz \
--to=jack@suse.cz \
--cc=anna.schumaker@netapp.com \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@primarydata.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;
as well as URLs for NNTP newsgroup(s).