Re: [PATCH-next 2/5] lib/test_vmalloc.c: add a new 'nr_threads' parameter
On Mon, Apr 05, 2021 at 07:39:20PM -0700, Andrew Morton wrote:
> On Sat, 3 Apr 2021 14:31:43 +0200 Uladzislau Rezki wrote:
>
> > >
> > > We may need to replaced that kcalloc() with kmvalloc() though...
> > >
> > Yep. If we limit to USHRT_MAX, the maximum amount of memory for
> > internal data would be ~12MB. Something like below:
> >
> > diff --git a/lib/test_vmalloc.c b/lib/test_vmalloc.c
> > index d337985e4c5e..a5103e3461bf 100644
> > --- a/lib/test_vmalloc.c
> > +++ b/lib/test_vmalloc.c
> > @@ -24,7 +24,7 @@
> > MODULE_PARM_DESC(name, msg) \
> >
> > __param(int, nr_threads, 0,
> > - "Number of workers to perform tests(min: 1 max: 1024)");
> > + "Number of workers to perform tests(min: 1 max: 65536)");
> >
> > __param(bool, sequential_test_order, false,
> > "Use sequential stress tests order");
> > @@ -469,13 +469,13 @@ init_test_configurtion(void)
> > {
> > /*
> > * A maximum number of workers is defined as hard-coded
> > -* value and set to 1024. We add such gap just in case
> > +* value and set to 65536. We add such gap just in case
> > * and for potential heavy stressing.
> > */
> > - nr_threads = clamp(nr_threads, 1, 1024);
> > + nr_threads = clamp(nr_threads, 1, 65536);
> >
> > /* Allocate the space for test instances. */
> > - tdriver = kcalloc(nr_threads, sizeof(*tdriver), GFP_KERNEL);
> > + tdriver = kvcalloc(nr_threads, sizeof(*tdriver), GFP_KERNEL);
> > if (tdriver == NULL)
> > return -1;
> >
> > @@ -555,7 +555,7 @@ static void do_concurrent_test(void)
> > i, t->stop - t->start);
> > }
> >
> > - kfree(tdriver);
> > + kvfree(tdriver);
> > }
> >
> > static int vmalloc_test_init(void)
> >
> > Does it sound reasonable for you?
>
> I think so. It's a test thing so let's give testers more flexibility,
> remembering that they don't need as much protection from their own
> mistakes.
>
OK. I will send one more extra patch then.
--
Vlad Rezki
Re: [PATCH-next 2/5] lib/test_vmalloc.c: add a new 'nr_threads' parameter
On Sat, 3 Apr 2021 14:31:43 +0200 Uladzislau Rezki wrote:
> >
> > We may need to replaced that kcalloc() with kmvalloc() though...
> >
> Yep. If we limit to USHRT_MAX, the maximum amount of memory for
> internal data would be ~12MB. Something like below:
>
> diff --git a/lib/test_vmalloc.c b/lib/test_vmalloc.c
> index d337985e4c5e..a5103e3461bf 100644
> --- a/lib/test_vmalloc.c
> +++ b/lib/test_vmalloc.c
> @@ -24,7 +24,7 @@
> MODULE_PARM_DESC(name, msg) \
>
> __param(int, nr_threads, 0,
> - "Number of workers to perform tests(min: 1 max: 1024)");
> + "Number of workers to perform tests(min: 1 max: 65536)");
>
> __param(bool, sequential_test_order, false,
> "Use sequential stress tests order");
> @@ -469,13 +469,13 @@ init_test_configurtion(void)
> {
> /*
> * A maximum number of workers is defined as hard-coded
> -* value and set to 1024. We add such gap just in case
> +* value and set to 65536. We add such gap just in case
> * and for potential heavy stressing.
> */
> - nr_threads = clamp(nr_threads, 1, 1024);
> + nr_threads = clamp(nr_threads, 1, 65536);
>
> /* Allocate the space for test instances. */
> - tdriver = kcalloc(nr_threads, sizeof(*tdriver), GFP_KERNEL);
> + tdriver = kvcalloc(nr_threads, sizeof(*tdriver), GFP_KERNEL);
> if (tdriver == NULL)
> return -1;
>
> @@ -555,7 +555,7 @@ static void do_concurrent_test(void)
> i, t->stop - t->start);
> }
>
> - kfree(tdriver);
> + kvfree(tdriver);
> }
>
> static int vmalloc_test_init(void)
>
> Does it sound reasonable for you?
I think so. It's a test thing so let's give testers more flexibility,
remembering that they don't need as much protection from their own
mistakes.
Re: [PATCH-next 2/5] lib/test_vmalloc.c: add a new 'nr_threads' parameter
> On Fri, 2 Apr 2021 22:22:34 +0200 "Uladzislau Rezki (Sony)"
> wrote:
>
> > By using this parameter we can specify how many workers are
> > created to perform vmalloc tests. By default it is one CPU.
> > The maximum value is set to 1024.
> >
> > As a result of this change a 'single_cpu_test' one becomes
> > obsolete, therefore it is no longer needed.
> >
>
> Why limit to 1024? Maybe testers want more - what's the downside to
> permitting that?
>
I was thinking mainly about if a tester issues enormous number of kthreads,
so a system is not able to handle it. Therefore i clamped that value to 1024.
>From the other hand we can give more wide permissions, in that case a
user should think more carefully about what is passed. For example we
can limit max value by USHRT_MAX what is 65536.
>
> We may need to replaced that kcalloc() with kmvalloc() though...
>
Yep. If we limit to USHRT_MAX, the maximum amount of memory for
internal data would be ~12MB. Something like below:
diff --git a/lib/test_vmalloc.c b/lib/test_vmalloc.c
index d337985e4c5e..a5103e3461bf 100644
--- a/lib/test_vmalloc.c
+++ b/lib/test_vmalloc.c
@@ -24,7 +24,7 @@
MODULE_PARM_DESC(name, msg) \
__param(int, nr_threads, 0,
- "Number of workers to perform tests(min: 1 max: 1024)");
+ "Number of workers to perform tests(min: 1 max: 65536)");
__param(bool, sequential_test_order, false,
"Use sequential stress tests order");
@@ -469,13 +469,13 @@ init_test_configurtion(void)
{
/*
* A maximum number of workers is defined as hard-coded
-* value and set to 1024. We add such gap just in case
+* value and set to 65536. We add such gap just in case
* and for potential heavy stressing.
*/
- nr_threads = clamp(nr_threads, 1, 1024);
+ nr_threads = clamp(nr_threads, 1, 65536);
/* Allocate the space for test instances. */
- tdriver = kcalloc(nr_threads, sizeof(*tdriver), GFP_KERNEL);
+ tdriver = kvcalloc(nr_threads, sizeof(*tdriver), GFP_KERNEL);
if (tdriver == NULL)
return -1;
@@ -555,7 +555,7 @@ static void do_concurrent_test(void)
i, t->stop - t->start);
}
- kfree(tdriver);
+ kvfree(tdriver);
}
static int vmalloc_test_init(void)
Does it sound reasonable for you?
--
Vlad Rezki
Re: [PATCH-next 2/5] lib/test_vmalloc.c: add a new 'nr_threads' parameter
On Fri, 2 Apr 2021 22:22:34 +0200 "Uladzislau Rezki (Sony)" wrote: > By using this parameter we can specify how many workers are > created to perform vmalloc tests. By default it is one CPU. > The maximum value is set to 1024. > > As a result of this change a 'single_cpu_test' one becomes > obsolete, therefore it is no longer needed. > Why limit to 1024? Maybe testers want more - what's the downside to permitting that? We may need to replaced that kcalloc() with kmvalloc() though...
