[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0a7dd23f-9f6f-46b5-8ef0-b09ea1b3ccd7@arm.com>
Date: Sat, 14 Jun 2025 15:57:26 +0530
From: Dev Jain <dev.jain@....com>
To: Uladzislau Rezki <urezki@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
LKML <linux-kernel@...r.kernel.org>, Baoquan He <bhe@...hat.com>,
Christoph Hellwig <hch@...radead.org>,
Oleksiy Avramchenko <oleksiy.avramchenko@...y.com>,
Ryan Roberts <ryan.roberts@....com>
Subject: Re: [PATCH 2/4] lib/test_vmalloc.c: Allow built-in execution
On 13/06/25 8:07 pm, Uladzislau Rezki wrote:
> On Fri, Jun 13, 2025 at 07:53:37PM +0530, Dev Jain wrote:
>> On 13/06/25 7:49 pm, Uladzislau Rezki wrote:
>>> Hello, Dev!
>>>
>>>> On 17/04/25 9:42 pm, Uladzislau Rezki (Sony) wrote:
>>>>> This patch removes the dependency on module loading ("m")
>>>>> for the vmalloc test suite, enabling it to be built directly
>>>>> into the kernel, so both ("=m") and ("=y") are supported.
>>>>>
>>>>> Motivation:
>>>>> - Faster debugging/testing of vmalloc code;
>>>>> - It allows to configure the test via kernel-boot parameters.
>>>>>
>>>>> Configuration example:
>>>>> test_vmalloc.nr_threads=64
>>>>> test_vmalloc.run_test_mask=7
>>>>> test_vmalloc.sequential_test_order=1
>>>>>
>>>>> Signed-off-by: Uladzislau Rezki (Sony) <urezki@...il.com>
>>>>> ---
>>>>> lib/Kconfig.debug | 3 +--
>>>>> lib/test_vmalloc.c | 5 +++--
>>>>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>>>>> index f9051ab610d54..166b9d830a85a 100644
>>>>> --- a/lib/Kconfig.debug
>>>>> +++ b/lib/Kconfig.debug
>>>>> @@ -2574,8 +2574,7 @@ config TEST_BITOPS
>>>>> config TEST_VMALLOC
>>>>> tristate "Test module for stress/performance analysis of vmalloc allocator"
>>>>> default n
>>>>> - depends on MMU
>>>>> - depends on m
>>>>> + depends on MMU
>>>>> help
>>>>> This builds the "test_vmalloc" module that should be used for
>>>>> stress and performance analysis. So, any new change for vmalloc
>>>>> diff --git a/lib/test_vmalloc.c b/lib/test_vmalloc.c
>>>>> index 4ab23e5e772d0..6d65ef725d42c 100644
>>>>> --- a/lib/test_vmalloc.c
>>>>> +++ b/lib/test_vmalloc.c
>>>>> @@ -591,10 +591,11 @@ static void do_concurrent_test(void)
>>>>> kvfree(tdriver);
>>>>> }
>>>>> -static int vmalloc_test_init(void)
>>>>> +static int __init vmalloc_test_init(void)
>>>>> {
>>>>> do_concurrent_test();
>>>>> - return -EAGAIN; /* Fail will directly unload the module */
>>>>> + /* Fail will directly unload the module */
>>>>> + return IS_BUILTIN(CONFIG_TEST_VMALLOC) ? 0:-EAGAIN;
>>>>> }
>>>>> module_init(vmalloc_test_init)
>>>> Hi Uladzislau,
>>>>
>>>> Post this patch I am seeing the following problem: while booting the kernel, this test is
>>>> executed and a particular testcase triggers a warning splat from the kernel, then the boot
>>>> gets stuck for 3-4 seconds, then proceeds. I am not an expert on modules so I don't know
>>>> what happened but I am guessing that when the test fails, the delay is due to module
>>>> unloading time...do you suggest a solution? I reverted your patch and then proceeded with
>>>> my work, so apologies for not having the dmesg log, if you need it I'll replicate, although
>>>> there is some subtest which has consistently been spitting out a warning on my Apple M3 Linux
>>>> VM and I have been just ignoring it for long : )
>>>>
>>> This is because CONFIG_TEST_VMALLOC=y is built-in in your case.
>> Actually, I have a usecase for test_vmalloc :) I wanted to test my
>> patches through the test, but the problem is that the moment it fails,
>> it gets unloaded and then I cannot use the test at runtime. Currently it
>> is set to =m in my .config.
>>
> Ah. It is unloaded itself when tests are done. Do not use the
> test_vmalloc.ko directly. Instead use test_vmalloc.sh script.
>
> It is located here: ./tools/testing/selftests/mm/test_vmalloc.sh
>
> Example: sudo ./test_vmalloc.sh nr_threads=HOW-MANY-CPU-YOU-have(digit) run_test_mask=7
This is what I have been doing. Before your patch, I was able to run the test multiple
times, even in case of failure. After the patch, it fails at boot time and unloads.
>
> --
> Uladzislau Rezki
Powered by blists - more mailing lists