Re: [External] [RFC 1/7] lib/test_vmalloc: Add non-block-alloc-test case

Uladzislau Rezki
2025-07-08T08:29:57Z

Hello, Adrian!

>
> > -----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.
>
It was added just to track the sleep-in-atomic issues. We do not need
that spin-lock in fact. Instead we can just invoke
preempt_disable/enable() to simulate the context which is not allowed
to trigger any schedule(), i.e. sleeping.

--
Uladzislau Rezki