From: David Rientjes <rientjes@google.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Andreas Dilger <andreas.dilger@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Ricardo M. Correia" <ricardo.correia@oracle.com>,
linux-mm@kvack.org, Brian Behlendorf <behlendorf1@llnl.gov>,
Dave Chinner <david@fromorbit.com>
Subject: Re: Propagating GFP_NOFS inside __vmalloc()
Date: Wed, 17 Nov 2010 13:24:38 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.00.1011171320190.10254@chino.kir.corp.google.com> (raw)
In-Reply-To: <20101117090457.GA30543@infradead.org>
On Wed, 17 Nov 2010, Christoph Hellwig wrote:
> As Dave mentioned XFS also needs GFP_NOFS allocations in the low-level
> vmap machinery, which is shared with vmalloc.
>
Ok, so vm_map_ram() probably needs to be modified to allow gfp_t to be
passed in after the pte wrappers are in place that can be used to avoid
the hard-wired GFP_KERNEL in arch code (Ricardo is working on that, I
believe?); once that's done, it's trivial to pass the gfp_t for xfs to
lower-level vmalloc code to allocate the necessary vmap_block, vmap_area,
and radix tree data structures from the slab allocator (they are all
order-0, at least).
I think the ultimate solution will be able to allow GFP_NOFS to be passed
into things like vm_map_ram() and __vmalloc() and then try to avoid new
additions and fix up the callers later, if possible, for the eventual
removal of all gfp_t formals from the vmalloc layer.
--
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2010-11-17 21:25 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-10 20:42 Ricardo M. Correia
2010-11-10 21:35 ` Ricardo M. Correia
2010-11-10 22:10 ` Dave Chinner
2010-11-11 20:06 ` Andrew Morton
2010-11-11 22:02 ` Ricardo M. Correia
2010-11-11 22:25 ` Andrew Morton
2010-11-11 22:45 ` Ricardo M. Correia
2010-11-11 23:19 ` Ricardo M. Correia
2010-11-11 23:27 ` Andrew Morton
2010-11-11 23:29 ` Ricardo M. Correia
2010-11-15 17:01 ` Ricardo M. Correia
2010-11-15 21:28 ` David Rientjes
2010-11-15 22:19 ` Ricardo M. Correia
2010-11-15 22:50 ` David Rientjes
2010-11-15 23:30 ` Ricardo M. Correia
2010-11-15 23:55 ` David Rientjes
2010-11-16 22:11 ` Andrew Morton
2010-11-17 7:18 ` Andreas Dilger
2010-11-17 7:24 ` Andrew Morton
2010-11-17 7:37 ` David Rientjes
2010-11-17 9:04 ` Christoph Hellwig
2010-11-17 21:24 ` David Rientjes [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=alpine.DEB.2.00.1011171320190.10254@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=andreas.dilger@oracle.com \
--cc=behlendorf1@llnl.gov \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=linux-mm@kvack.org \
--cc=ricardo.correia@oracle.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