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: [PATCH 1/4] mm/vmalloc: alloc GFP_NO{FS,IO} for vmalloc
Date: Mon, 25 Oct 2021 17:02:20 +0200 [thread overview]
Message-ID: <20211025150223.13621-2-mhocko@kernel.org> (raw)
In-Reply-To: <20211025150223.13621-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..c6cc77d2f366 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)) == 0)
+ 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)) == 0)
+ 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-25 15:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-25 15:02 [PATCH 0/4] extend vmalloc support for constrained allocations Michal Hocko
2021-10-25 15:02 ` Michal Hocko [this message]
2021-10-25 15:02 ` [PATCH 2/4] mm/vmalloc: add support for __GFP_NOFAIL Michal Hocko
2021-10-25 22:59 ` NeilBrown
2021-10-26 7:03 ` Michal Hocko
2021-10-26 10:30 ` NeilBrown
2021-10-26 11:29 ` Michal Hocko
2021-10-26 15:48 ` Uladzislau Rezki
2021-10-26 16:28 ` Michal Hocko
2021-10-26 19:33 ` Uladzislau Rezki
2021-10-27 6:46 ` Michal Hocko
2021-10-27 17:55 ` Uladzislau Rezki
2021-10-29 7:57 ` Michal Hocko
2021-10-29 14:05 ` Uladzislau Rezki
2021-10-29 14:45 ` Michal Hocko
2021-10-29 17:23 ` Uladzislau Rezki
2021-10-25 15:02 ` [PATCH 3/4] mm/vmalloc: be more explicit about supported gfp flags Michal Hocko
2021-10-25 23:26 ` NeilBrown
2021-10-26 7:10 ` Michal Hocko
2021-10-26 10:43 ` NeilBrown
2021-10-26 12:20 ` Michal Hocko
2021-10-25 15:02 ` [PATCH 4/4] mm: allow !GFP_KERNEL allocations for kvmalloc Michal Hocko
2021-10-25 23:34 ` NeilBrown
2021-10-26 7:15 ` Michal Hocko
2021-10-26 10:48 ` NeilBrown
2021-10-26 12:23 ` 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=20211025150223.13621-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 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).