From: Marco Elver <elver@google.com>
To: "Uladzislau Rezki (Sony)" <urezki@gmail.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Michal Hocko <mhocko@kernel.org>, Baoquan He <bhe@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Alexander Potapenko <glider@google.com>,
kasan-dev@googlegroups.com
Subject: Re: [PATCH 0/8] __vmalloc() and no-block support
Date: Thu, 7 Aug 2025 13:01:00 +0200 [thread overview]
Message-ID: <aJSHbFviIiB2oN5G@elver.google.com> (raw)
In-Reply-To: <20250807075810.358714-1-urezki@gmail.com>
On Thu, Aug 07, 2025 at 09:58AM +0200, Uladzislau Rezki (Sony) wrote:
> Hello.
>
> This is a second series of making __vmalloc() to support GFP_ATOMIC and
> GFP_NOWAIT flags. It tends to improve the non-blocking behaviour.
>
> The first one can be found here:
>
> https://lore.kernel.org/all/20250704152537.55724-1-urezki@gmail.com/
>
> that was an RFC. Using this series for testing i have not found more
> places which can trigger: scheduling during atomic. Though there is
> one which requires attention. I will explain in [1].
>
> Please note, non-blocking gets improved in the __vmalloc() call only,
> i.e. vmalloc_huge() still contains in its paths many cond_resched()
> points and can not be used as non-blocking as of now.
>
> [1] The vmap_pages_range_noflush() contains the kmsan_vmap_pages_range_noflush()
> external implementation for KCSAN specifically which is hard coded to GFP_KERNEL.
> The kernel should be built with CONFIG_KCSAN option. To me it looks like not
> straight forward to run such kernel on my box, therefore i need more time to
> investigate what is wrong with CONFIG_KCSAN and my env.
KMSAN or KCSAN?
[+Cc KMSAN maintainers]
next prev parent reply other threads:[~2025-08-07 11:01 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-07 7:58 [PATCH 0/8] __vmalloc() and no-block support Uladzislau Rezki (Sony)
2025-08-07 7:58 ` [PATCH 1/8] lib/test_vmalloc: add no_block_alloc_test case Uladzislau Rezki (Sony)
2025-08-07 7:58 ` [PATCH 2/8] lib/test_vmalloc: Remove xfail condition check Uladzislau Rezki (Sony)
2025-08-07 7:58 ` [PATCH 3/8] mm/vmalloc: Support non-blocking GFP flags in alloc_vmap_area() Uladzislau Rezki (Sony)
2025-08-07 11:20 ` Michal Hocko
2025-08-08 9:59 ` Uladzislau Rezki
2025-08-18 2:11 ` Baoquan He
2025-08-07 7:58 ` [PATCH 4/8] mm/vmalloc: Remove cond_resched() in vm_area_alloc_pages() Uladzislau Rezki (Sony)
2025-08-07 11:22 ` Michal Hocko
2025-08-08 10:08 ` Uladzislau Rezki
2025-08-18 2:14 ` Baoquan He
2025-08-07 7:58 ` [PATCH 5/8] mm/kasan, mm/vmalloc: Respect GFP flags in kasan_populate_vmalloc() Uladzislau Rezki (Sony)
2025-08-07 16:05 ` Andrey Ryabinin
2025-08-08 10:18 ` Uladzislau Rezki
2025-08-07 7:58 ` [PATCH 6/8] mm/vmalloc: Defer freeing partly initialized vm_struct Uladzislau Rezki (Sony)
2025-08-07 11:25 ` Michal Hocko
2025-08-08 10:37 ` Uladzislau Rezki
2025-08-18 4:21 ` Baoquan He
2025-08-18 13:02 ` Uladzislau Rezki
2025-08-19 8:56 ` Baoquan He
2025-08-19 9:20 ` Uladzislau Rezki
2025-08-07 7:58 ` [PATCH 7/8] mm/vmalloc: Support non-blocking GFP flags in __vmalloc_area_node() Uladzislau Rezki (Sony)
2025-08-07 11:54 ` Michal Hocko
2025-08-08 11:54 ` Uladzislau Rezki
2025-08-18 4:35 ` Baoquan He
2025-08-18 13:08 ` Uladzislau Rezki
2025-08-19 8:46 ` Baoquan He
2025-08-07 7:58 ` [PATCH 8/8] mm: Drop __GFP_DIRECT_RECLAIM flag if PF_MEMALLOC is set Uladzislau Rezki (Sony)
2025-08-07 11:58 ` Michal Hocko
2025-08-08 13:12 ` Uladzislau Rezki
2025-08-08 14:16 ` Michal Hocko
2025-08-08 16:56 ` Uladzislau Rezki
2025-08-07 11:01 ` Marco Elver [this message]
2025-08-08 8:48 ` [PATCH 0/8] __vmalloc() and no-block support Uladzislau Rezki
2025-08-23 9:35 ` Uladzislau Rezki
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=aJSHbFviIiB2oN5G@elver.google.com \
--to=elver@google.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=urezki@gmail.com \
--cc=vbabka@suse.cz \
/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.