All of lore.kernel.org
 help / color / mirror / Atom feed
From: Uladzislau Rezki <urezki@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Uladzislau Rezki (Sony)" <urezki@gmail.com>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
	Hillf Danton <hdanton@sina.com>, Michal Hocko <mhocko@suse.com>,
	Matthew Wilcox <willy@infradead.org>,
	Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH-next 2/5] lib/test_vmalloc.c: add a new 'nr_threads' parameter
Date: Sat, 3 Apr 2021 14:31:43 +0200	[thread overview]
Message-ID: <20210403123143.GA38147@pc638.lan> (raw)
In-Reply-To: <20210402145934.719192be298eadbeecb321d2@linux-foundation.org>

> On Fri,  2 Apr 2021 22:22:34 +0200 "Uladzislau Rezki (Sony)" <urezki@gmail.com> 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


  reply	other threads:[~2021-04-03 12:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-02 20:22 [PATCH-next 1/5] lib/test_vmalloc.c: remove two kvfree_rcu() tests Uladzislau Rezki (Sony)
2021-04-02 20:22 ` [PATCH-next 2/5] lib/test_vmalloc.c: add a new 'nr_threads' parameter Uladzislau Rezki (Sony)
2021-04-02 21:59   ` Andrew Morton
2021-04-03 12:31     ` Uladzislau Rezki [this message]
2021-04-06  2:39       ` Andrew Morton
2021-04-06 10:05         ` Uladzislau Rezki
2021-04-02 20:22 ` [PATCH-next 3/5] vm/test_vmalloc.sh: adapt for updated driver interface Uladzislau Rezki (Sony)
2021-04-02 20:22 ` [PATCH-next 4/5] mm/vmalloc: refactor the preloading loagic Uladzislau Rezki (Sony)
2021-04-02 20:22 ` [PATCH-next 5/5] mm/vmalloc: remove an empty line Uladzislau Rezki (Sony)
2021-04-02 20:30   ` Souptick Joarder
2021-04-02 20:58     ` 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=20210403123143.GA38147@pc638.lan \
    --to=urezki@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hdanton@sina.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=oleksiy.avramchenko@sonymobile.com \
    --cc=rostedt@goodmis.org \
    --cc=willy@infradead.org \
    /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.