From: John Hubbard <jhubbard@nvidia.com>
To: Jan Kara <jack@suse.cz>, Chaitanya Kulkarni <chaitanyak@nvidia.com>
Cc: Christoph Hellwig <hch@lst.de>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: RFA (Request for Advice): block/bio: get_user_pages() --> pin_user_pages()
Date: Mon, 24 Jan 2022 11:34:25 -0800 [thread overview]
Message-ID: <bdc63efb-5f5f-73ee-5785-ea28c576c52a@nvidia.com> (raw)
In-Reply-To: <20220124121903.fono7exjgqi22ify@quack3.lan>
On 1/24/22 04:19, Jan Kara wrote:
...
>> this maybe wrong but thinking out loudly, have you consider adding a
>> ZERO_PAGE() address check since it should have a unique same
This crossed my mind, but I thought I might be missing something better
on the submission side, such as some way to do all of this without a
zero page.
>> address for each ZERO_PAGE() (unless I'm totally wrong here) and
>> using this check you can distinguish between ZERO_PAGE() and
>> non ZERO_PAGE() on the bio list in bio_release_pages().
>
> Well, that is another option but it seems a bit ugly and also on some
> architectures (e.g. s390 AFAICS) there can be multiple zero pages (due to
> coloring) so the test for zero page is not completely trivial (probably we
> would have to grow some is_zero_page() checking function implemented
> separately for each arch).
Good point. And adding an is_zero_page() function would also make some
of these invocations correct across all architectures:
is_zero_pfn(page_to_pfn(page))
...so it would also be a fix or at least an upgrade.
I had also wondered why there is no is_zero_page() wrapper function for
the above invocation. Maybe because there are only four call sites and
no one saw it as worthwhile yet.
Anyway, this looks viable, thanks for the quick responses!
thanks,
--
John Hubbard
NVIDIA
next prev parent reply other threads:[~2022-01-24 20:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-24 7:52 RFA (Request for Advice): block/bio: get_user_pages() --> pin_user_pages() John Hubbard
2022-01-24 10:05 ` Jan Kara
2022-01-24 10:38 ` Chaitanya Kulkarni
2022-01-24 12:19 ` Jan Kara
2022-01-24 19:34 ` John Hubbard [this message]
2022-01-24 21:06 ` Jan Kara
2022-01-24 21:06 ` John Hubbard
2022-01-24 22:17 ` Jan Kara
2022-01-24 13:18 ` Matthew Wilcox
2022-01-24 19:48 ` John Hubbard
2022-01-26 5:42 ` Chaitanya Kulkarni
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=bdc63efb-5f5f-73ee-5785-ea28c576c52a@nvidia.com \
--to=jhubbard@nvidia.com \
--cc=chaitanyak@nvidia.com \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@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