From: Al Viro <viro@ZenIV.linux.org.uk>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Dave Chinner <david@fromorbit.com>,
Ming Lei <ming.lei@canonical.com>
Subject: Re: __vmalloc() vs. GFP_NOIO/GFP_NOFS
Date: Sun, 3 Jan 2016 16:56:13 +0000 [thread overview]
Message-ID: <20160103165613.GL9938@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20160103071246.GK9938@ZenIV.linux.org.uk>
On Sun, Jan 03, 2016 at 07:12:47AM +0000, Al Viro wrote:
> Allocation page tables doesn't have gfp argument at all. Trying to propagate
> it down there could be done, but it's not attractive.
While we are at it, is there ever a reason to _not_ pass __GFP_HIGHMEM in
__vmalloc() flags? After all, we explicitly put the pages we'd allocated
into the page table at vmalloc range we'd grabbed and these are the
addresses visible to caller. Is there any point in having another alias
for those pages?
vmalloc() itself passes __GFP_HIGHMEM and so does a lot of __vmalloc()
callers; in fact, most of those that do not look like a result of
"we want vmalloc(), but we want to avoid it going into fs code and possibly
deadlocking us; vmalloc() has no gfp_t argument, so let's use __vmalloc()
and give it GFP_NOFS".
Another very weird thing is the use of GFP_ATOMIC by alloc_large_system_hash();
if we want _that_ honoured, we'd probably have to pass gfp_t to alloc_one_pmd()
and friends, but I'm not sure what exactly is that caller requesting.
Confused...
--
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:[~2016-01-03 16:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-03 7:12 __vmalloc() vs. GFP_NOIO/GFP_NOFS Al Viro
2016-01-03 16:56 ` Al Viro [this message]
2016-01-03 20:12 ` Dave Chinner
2016-01-03 20:35 ` Al Viro
2016-01-05 15:35 ` Michal Hocko
2016-01-04 13:40 ` Tetsuo Handa
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=20160103165613.GL9938@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ming.lei@canonical.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).