From: Jerome Glisse <jglisse@redhat.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-block@vger.kernel.org
Subject: Re: [LSF/MM TOPIC] Killing reliance on struct page->mapping
Date: Wed, 31 Jan 2018 13:13:56 -0500 [thread overview]
Message-ID: <20180131181356.GG2912@redhat.com> (raw)
In-Reply-To: <20180131175558.GA30522@ZenIV.linux.org.uk>
On Wed, Jan 31, 2018 at 05:55:58PM +0000, Al Viro wrote:
> On Wed, Jan 31, 2018 at 12:42:45PM -0500, Jerome Glisse wrote:
>
> > For block devices the idea is to use struct page and buffer_head (first one of
> > a page) as a key to find mapping (struct address_space) back.
>
> Details, please...
Note that i am not talking about block device page (i am excluding
those from that). So just regular filesystem page (ext*,xfs,btrfs,
...).
So in block device context AFAIK only time when you need mapping is
if they are some I/O error. Given than i am doing this with intent to
write protect the page one can argue that i can wait for all writeback
to complete before proceeding. At that time, it does not matter to block
device if page->mapping is no longer an address_space because the block
device code is done with the page and has forget about it.
That's one solution, another one is to have struct bio_vec store
buffer_head pointer and not page pointer, from buffer_head you can
find struct page and using buffer_head and struct page pointer you
can walk the KSM rmap_item chain to find back the mapping. This
would be needed on I/O error for pending writeback of a newly write
protected page, so one can argue that the overhead of the chain lookup
to find back the mapping against which to report IO error, is an
acceptable cost.
Another solution is to override the writeback end callback with
special one capable of finding the mapping from struct page and bio
pointer. This would not need any change to block device code. It
would have the same overhead thought as solution 2 above.
My intention was to stick to first solution (wait for writeback and
make no modification to block device struct or function). Then latter
if it make sense to add support to write protect a page before write
back is done.
Cheers,
Jerome
--
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>
next prev parent reply other threads:[~2018-01-31 18:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-30 0:43 [LSF/MM TOPIC] Killing reliance on struct page->mapping Jerome Glisse
2018-01-31 16:56 ` Al Viro
2018-01-31 17:42 ` Jerome Glisse
2018-01-31 17:55 ` Al Viro
2018-01-31 18:13 ` Jerome Glisse [this message]
2018-02-01 15:34 ` [Lsf-pc] " Jens Axboe
2018-02-01 15:57 ` Jerome Glisse
2018-02-01 16:00 ` Jens Axboe
2018-02-01 16:33 ` Jerome Glisse
2018-02-01 12:27 ` Kirill A. Shutemov
2018-02-01 13:22 ` Jerome Glisse
2018-01-31 17:09 ` Igor Stoppa
2018-01-31 17:48 ` Jerome Glisse
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=20180131181356.GG2912@redhat.com \
--to=jglisse@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
/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).