From: Michal Hocko <mhocko@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Dave Chinner <david@fromorbit.com>, Neil Brown <neilb@suse.de>,
Christoph Hellwig <hch@lst.de>,
Uladzislau Rezki <urezki@gmail.com>,
<linux-fsdevel@vger.kernel.org>, <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Ilya Dryomov <idryomov@gmail.com>,
Jeff Layton <jlayton@kernel.org>, Michal Hocko <mhocko@suse.com>
Subject: [PATCH v2 1/4] mm/vmalloc: alloc GFP_NO{FS,IO} for vmalloc
Date: Mon, 22 Nov 2021 16:32:30 +0100 [thread overview]
Message-ID: <20211122153233.9924-2-mhocko@kernel.org> (raw)
In-Reply-To: <20211122153233.9924-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 d2a00ad4e1dd..17ca7001de1f 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2926,6 +2926,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;
@@ -2967,8 +2969,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(orig_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-11-22 15:32 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-22 15:32 [PATCH v2 0/4] extend vmalloc support for constrained allocations Michal Hocko
2021-11-22 15:32 ` Michal Hocko [this message]
2021-11-23 19:05 ` [PATCH v2 1/4] mm/vmalloc: alloc GFP_NO{FS,IO} for vmalloc Uladzislau Rezki
2021-11-26 15:13 ` Vlastimil Babka
2021-11-22 15:32 ` [PATCH v2 2/4] mm/vmalloc: add support for __GFP_NOFAIL Michal Hocko
2021-11-23 19:01 ` Uladzislau Rezki
2021-11-23 20:09 ` Michal Hocko
2021-11-24 20:46 ` Uladzislau Rezki
2021-11-24 1:02 ` Andrew Morton
2021-11-24 3:16 ` NeilBrown
2021-11-24 3:48 ` Andrew Morton
2021-11-24 5:23 ` NeilBrown
2021-11-25 0:32 ` Theodore Y. Ts'o
2021-11-26 14:50 ` Vlastimil Babka
2021-11-26 15:09 ` Michal Hocko
2021-11-24 23:45 ` Dave Chinner
2021-11-24 8:43 ` Michal Hocko
2021-11-24 20:37 ` Uladzislau Rezki
2021-11-25 8:48 ` Michal Hocko
2021-11-25 18:40 ` Uladzislau Rezki
2021-11-25 19:21 ` Michal Hocko
2021-11-24 20:11 ` Uladzislau Rezki
2021-11-25 8:46 ` Michal Hocko
2021-11-25 18:02 ` Uladzislau Rezki
2021-11-25 19:24 ` Michal Hocko
2021-11-25 20:03 ` Uladzislau Rezki
2021-11-25 20:13 ` Michal Hocko
2021-11-25 20:21 ` Uladzislau Rezki
2021-11-26 10:48 ` Michal Hocko
2021-11-28 0:00 ` Andrew Morton
2021-11-29 8:56 ` Michal Hocko
2021-11-26 15:32 ` Vlastimil Babka
2021-11-22 15:32 ` [PATCH v2 3/4] mm/vmalloc: be more explicit about supported gfp flags Michal Hocko
2021-11-23 18:58 ` Uladzislau Rezki
2021-11-26 15:39 ` Vlastimil Babka
2021-11-22 15:32 ` [PATCH v2 4/4] mm: allow !GFP_KERNEL allocations for kvmalloc Michal Hocko
2021-11-23 18:57 ` Uladzislau Rezki
2021-11-23 19:02 ` Uladzislau Rezki
2021-11-26 15:50 ` Vlastimil Babka
2021-11-24 22:55 ` [PATCH v2 0/4] extend vmalloc support for constrained allocations Dave Chinner
2021-11-25 8:58 ` Michal Hocko
2021-11-25 9:30 ` Michal Hocko
2021-11-25 21:30 ` Dave Chinner
2021-11-26 9:20 ` Vlastimil Babka
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=20211122153233.9924-2-mhocko@kernel.org \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--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.