From: Adrian Huang12 <ahuang12@lenovo.com>
To: "Uladzislau Rezki (Sony)" <urezki@gmail.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.org>,
LKML <linux-kernel@vger.kernel.org>, Baoquan He <bhe@redhat.com>
Subject: RE: [External] [RFC 1/7] lib/test_vmalloc: Add non-block-alloc-test case
Date: Tue, 8 Jul 2025 05:59:40 +0000 [thread overview]
Message-ID: <TPZP295MB00136CCFA28CEAAF7E11B840B34EA@TPZP295MB0013.TWNP295.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <20250704152537.55724-2-urezki@gmail.com>
Hi Uladzislau,
> -----Original Message-----
> From: owner-linux-mm@kvack.org <owner-linux-mm@kvack.org> On Behalf
> Of Uladzislau Rezki (Sony)
> Sent: Friday, July 4, 2025 11:26 PM
> To: linux-mm@kvack.org; Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@kernel.org>; LKML
> <linux-kernel@vger.kernel.org>; Baoquan He <bhe@redhat.com>; Uladzislau
> Rezki <urezki@gmail.com>
> Subject: [External] [RFC 1/7] lib/test_vmalloc: Add non-block-alloc-test case
>
> Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
> ---
> lib/test_vmalloc.c | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/lib/test_vmalloc.c b/lib/test_vmalloc.c index
> 1b0b59549aaf..9e3429dfe176 100644
> --- a/lib/test_vmalloc.c
> +++ b/lib/test_vmalloc.c
> @@ -54,6 +54,7 @@ __param(int, run_test_mask, INT_MAX,
> "\t\tid: 256, name: kvfree_rcu_1_arg_vmalloc_test\n"
> "\t\tid: 512, name: kvfree_rcu_2_arg_vmalloc_test\n"
> "\t\tid: 1024, name: vm_map_ram_test\n"
> + "\t\tid: 2048, name: no_block_alloc_test\n"
> /* Add a new test case description here. */ );
>
> @@ -283,6 +284,31 @@ static int fix_size_alloc_test(void)
> return 0;
> }
>
> +static DEFINE_SPINLOCK(no_block_alloc_lock);
> +
> +static int no_block_alloc_test(void)
> +{
> + void *ptr;
> + u8 rnd;
> + int i;
> +
> + for (i = 0; i < test_loop_count; i++) {
> + rnd = get_random_u8();
> +
> + spin_lock(&no_block_alloc_lock);
Since there is no shared data to be protected, do we need this lock for serialization? Any concerns?
It spent 18 minutes for this test (256-core server):
# time modprobe test_vmalloc nr_threads=$(nproc) run_test_mask=0x800
real 18m6.099s
user 0m0.002s
sys 0m4.555s
Without the lock, it spent 41 seconds (Have run for 300+ tests without any failure: 256-core server):
# time modprobe test_vmalloc nr_threads=$(nproc) run_test_mask=0x800
real 0m41.367s
user 0m0.003s
sys 0m5.758s
Would it be better to run this test concurrently? That said, it can also verify the scalability problem when the number of CPUs grow.
> + ptr = __vmalloc(PAGE_SIZE, (rnd % 2) ? GFP_NOWAIT :
> GFP_ATOMIC);
> + spin_unlock(&no_block_alloc_lock);
> +
> + if (!ptr)
> + return -1;
> +
> + *((__u8 *)ptr) = 0;
> + vfree(ptr);
> + }
> +
> + return 0;
> +}
> +
> static int
> pcpu_alloc_test(void)
> {
> @@ -410,6 +436,7 @@ static struct test_case_desc test_case_array[] = {
> { "kvfree_rcu_1_arg_vmalloc_test", kvfree_rcu_1_arg_vmalloc_test },
> { "kvfree_rcu_2_arg_vmalloc_test", kvfree_rcu_2_arg_vmalloc_test },
> { "vm_map_ram_test", vm_map_ram_test },
> + { "no_block_alloc_test", no_block_alloc_test },
> /* Add a new test case here. */
> };
>
> --
> 2.39.5
>
next prev parent reply other threads:[~2025-07-08 6:00 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-04 15:25 [RFC 0/7] vmallloc and non-blocking GFPs Uladzislau Rezki (Sony)
2025-07-04 15:25 ` [RFC 1/7] lib/test_vmalloc: Add non-block-alloc-test case Uladzislau Rezki (Sony)
2025-07-08 5:59 ` Adrian Huang12 [this message]
2025-07-08 8:29 ` [External] " Uladzislau Rezki
2025-07-04 15:25 ` [RFC 2/7] mm/vmalloc: Support non-blocking GFP flags in alloc_vmap_area() Uladzislau Rezki (Sony)
2025-07-07 7:11 ` Michal Hocko
2025-07-08 12:34 ` Uladzislau Rezki
2025-07-08 15:17 ` Michal Hocko
2025-07-08 16:45 ` Uladzislau Rezki
2025-07-04 15:25 ` [RFC 3/7] mm/vmalloc: Avoid cond_resched() when blocking is not permitted Uladzislau Rezki (Sony)
2025-07-07 7:11 ` Michal Hocko
2025-07-08 12:29 ` Uladzislau Rezki
2025-07-04 15:25 ` [RFC 4/7] mm/kasan, mm/vmalloc: Respect GFP flags in kasan_populate_vmalloc() Uladzislau Rezki (Sony)
2025-07-07 1:47 ` Baoquan He
2025-07-08 1:15 ` Baoquan He
2025-07-08 8:30 ` Uladzislau Rezki
2025-07-04 15:25 ` [RFC 5/7] mm/vmalloc: Defer freeing partly initialized vm_struct Uladzislau Rezki (Sony)
2025-07-04 15:25 ` [RFC 6/7] mm/vmalloc: Support non-blocking GFP flags in __vmalloc_area_node() Uladzislau Rezki (Sony)
2025-07-07 7:13 ` Michal Hocko
2025-07-08 12:27 ` Uladzislau Rezki
2025-07-08 15:22 ` Michal Hocko
2025-07-09 11:20 ` Uladzislau Rezki
2025-07-08 15:47 ` Michal Hocko
2025-07-09 13:45 ` Uladzislau Rezki
2025-07-04 15:25 ` [RFC 7/7] mm: Drop __GFP_DIRECT_RECLAIM flag if PF_MEMALLOC is set Uladzislau Rezki (Sony)
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=TPZP295MB00136CCFA28CEAAF7E11B840B34EA@TPZP295MB0013.TWNP295.PROD.OUTLOOK.COM \
--to=ahuang12@lenovo.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--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