From: Michal Hocko <mhocko@kernel.org>
To: <linux-mm@kvack.org>
Cc: Dave Chinner <david@fromorbit.com>, Neil Brown <neilb@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Hellwig <hch@infradead.org>,
Uladzislau Rezki <urezki@gmail.com>,
<linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Ilya Dryomov <idryomov@gmail.com>,
Jeff Layton <jlayton@kernel.org>, Michal Hocko <mhocko@suse.com>
Subject: [RFC 1/3] mm/vmalloc: alloc GFP_NO{FS,IO} for vmalloc
Date: Mon, 18 Oct 2021 13:47:10 +0200 [thread overview]
Message-ID: <20211018114712.9802-2-mhocko@kernel.org> (raw)
In-Reply-To: <20211018114712.9802-1-mhocko@kernel.org>
From: Michal Hocko <mhocko@suse.com>
vmalloc historically hasn't supported GFP_NO{FS,IO} requests because
page table allocations do not support externally provided gfp mask
and performed GFP_KERNEL like allocations.
Since few years we have scope (memalloc_no{fs,io}_{save,restore}) APIs
to enforce NOFS and NOIO constrains implicitly to all allocators within
the scope. There was a hope that those scopes would be defined on a
higher level when the reclaim recursion boundary starts/stops (e.g. when
a lock required during the memory reclaim is required etc.). It seems
that not all NOFS/NOIO users have adopted this approach and instead
they have taken a workaround approach to wrap a single [k]vmalloc
allocation by a scope API.
These workarounds do not serve the purpose of a better reclaim recursion
documentation and reduction of explicit GFP_NO{FS,IO} usege so let's
just provide them with the semantic they are asking for without a need
for workarounds.
Add support for GFP_NOFS and GFP_NOIO to vmalloc directly. All internal
allocations already comply with the given gfp_mask. The only current
exception is vmap_pages_range which maps kernel page tables. Infer the
proper scope API based on the given gfp mask.
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
mm/vmalloc.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index d77830ff604c..7455c89598d3 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2889,6 +2889,8 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
unsigned long array_size;
unsigned int nr_small_pages = size >> PAGE_SHIFT;
unsigned int page_order;
+ unsigned int flags;
+ int ret;
array_size = (unsigned long)nr_small_pages * sizeof(struct page *);
gfp_mask |= __GFP_NOWARN;
@@ -2930,8 +2932,24 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
goto fail;
}
- if (vmap_pages_range(addr, addr + size, prot, area->pages,
- page_shift) < 0) {
+ /*
+ * page tables allocations ignore external gfp mask, enforce it
+ * by the scope API
+ */
+ if ((gfp_mask & (__GFP_FS | __GFP_IO)) == __GFP_IO)
+ flags = memalloc_nofs_save();
+ else if (!(gfp_mask & (__GFP_FS | __GFP_IO)))
+ flags = memalloc_noio_save();
+
+ ret = vmap_pages_range(addr, addr + size, prot, area->pages,
+ page_shift);
+
+ if ((gfp_mask & (__GFP_FS | __GFP_IO)) == __GFP_IO)
+ memalloc_nofs_restore(flags);
+ else if (!(gfp_mask & (__GFP_FS | __GFP_IO)))
+ memalloc_noio_restore(flags);
+
+ if (ret < 0) {
warn_alloc(gfp_mask, NULL,
"vmalloc error: size %lu, failed to map pages",
area->nr_pages * PAGE_SIZE);
--
2.30.2
next prev parent reply other threads:[~2021-10-18 11:47 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-18 11:47 [RFC 0/3] extend vmalloc support for constrained allocations Michal Hocko
2021-10-18 11:47 ` Michal Hocko [this message]
2021-10-19 0:44 ` [RFC 1/3] mm/vmalloc: alloc GFP_NO{FS,IO} for vmalloc NeilBrown
2021-10-19 6:59 ` Michal Hocko
2021-10-18 11:47 ` [RFC 2/3] mm/vmalloc: add support for __GFP_NOFAIL Michal Hocko
2021-10-18 16:24 ` kernel test robot
2021-10-18 16:24 ` kernel test robot
2021-10-18 16:48 ` Michal Hocko
2021-10-18 18:15 ` kernel test robot
2021-10-18 18:15 ` kernel test robot
2021-10-19 11:06 ` Uladzislau Rezki
2021-10-19 11:52 ` Michal Hocko
2021-10-19 19:46 ` Uladzislau Rezki
2021-10-20 8:25 ` Michal Hocko
2021-10-20 9:18 ` Michal Hocko
2021-10-20 13:54 ` Uladzislau Rezki
2021-10-20 14:06 ` Michal Hocko
2021-10-20 14:29 ` Uladzislau Rezki
2021-10-20 14:53 ` Michal Hocko
2021-10-20 15:00 ` Uladzislau Rezki
2021-10-20 19:24 ` Uladzislau Rezki
2021-10-21 8:56 ` Michal Hocko
2021-10-21 10:13 ` NeilBrown
2021-10-21 10:27 ` Michal Hocko
2021-10-21 10:40 ` Uladzislau Rezki
2021-10-21 22:49 ` NeilBrown
2021-10-22 8:18 ` Michal Hocko
2021-10-25 9:48 ` Uladzislau Rezki
2021-10-25 11:20 ` Michal Hocko
2021-10-25 14:30 ` Uladzislau Rezki
2021-10-25 14:56 ` Michal Hocko
2021-10-25 23:50 ` NeilBrown
2021-10-26 7:16 ` Michal Hocko
2021-10-26 10:24 ` NeilBrown
2021-10-26 14:25 ` Uladzislau Rezki
2021-10-26 14:43 ` Michal Hocko
2021-10-26 15:40 ` Uladzislau Rezki
2021-10-20 8:25 ` [PATCH] mm/vmalloc: be more explicit about supported gfp flags Michal Hocko
2021-10-18 11:47 ` [RFC 3/3] mm: allow !GFP_KERNEL allocations for kvmalloc Michal Hocko
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=20211018114712.9802-2-mhocko@kernel.org \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=idryomov@gmail.com \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=neilb@suse.de \
--cc=urezki@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.