From: Alexander Gordeev <agordeev@linux.ibm.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>,
Balamuruhan S <bala24@linux.vnet.ibm.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@redhat.com>
Subject: Re: [PATCH v2 1/3] perf bench numa: use numa_node_to_cpus() to bind tasks to nodes
Date: Tue, 11 Aug 2020 10:11:11 +0200 [thread overview]
Message-ID: <20200811081111.GA31614@oc3871087118.ibm.com> (raw)
In-Reply-To: <CAM9d7cjLA29eOm6UU5FVE-Zeg7wm4bJaSdwMOH=ghDn=hfBo=A@mail.gmail.com>
On Tue, Aug 11, 2020 at 04:26:50PM +0900, Namhyung Kim wrote:
> Hello,
>
> On Mon, Aug 10, 2020 at 3:22 PM Alexander Gordeev
> <agordeev@linux.ibm.com> wrote:
> >
> > It is currently assumed that each node contains at most
> > nr_cpus/nr_nodes CPUs and node CPU ranges do not overlap.
> > That assumption is generally incorrect as there are archs
> > where a CPU number does not depend on to its node number.
> >
> > This update removes the described assumption by simply calling
> > numa_node_to_cpus() interface and using the returned mask for
> > binding CPUs to nodes. It also tightens a cpumask allocation
> > failure check a bit.
> >
> > Cc: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
> > Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
> > Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> > Cc: Balamuruhan S <bala24@linux.vnet.ibm.com>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> > Cc: Jiri Olsa <jolsa@redhat.com>
> > Cc: Namhyung Kim <namhyung@kernel.org>
> > Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
> > ---
> > tools/perf/bench/numa.c | 27 +++++++++++++--------------
> > 1 file changed, 13 insertions(+), 14 deletions(-)
> >
> > diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c
> > index 5797253..23e224e 100644
> > --- a/tools/perf/bench/numa.c
> > +++ b/tools/perf/bench/numa.c
> > @@ -247,12 +247,13 @@ static int is_node_present(int node)
> > */
> > static bool node_has_cpus(int node)
> > {
> > - struct bitmask *cpu = numa_allocate_cpumask();
> > + struct bitmask *cpumask = numa_allocate_cpumask();
> > unsigned int i;
> >
> > - if (cpu && !numa_node_to_cpus(node, cpu)) {
> > - for (i = 0; i < cpu->size; i++) {
> > - if (numa_bitmask_isbitset(cpu, i))
> > + BUG_ON(!cpumask);
> > + if (!numa_node_to_cpus(node, cpumask)) {
> > + for (i = 0; i < cpumask->size; i++) {
> > + if (numa_bitmask_isbitset(cpumask, i))
> > return true;
> > }
> > }
> > @@ -288,14 +289,10 @@ static cpu_set_t bind_to_cpu(int target_cpu)
> >
> > static cpu_set_t bind_to_node(int target_node)
> > {
> > - int cpus_per_node = g->p.nr_cpus / nr_numa_nodes();
> > cpu_set_t orig_mask, mask;
> > int cpu;
> > int ret;
> >
> > - BUG_ON(cpus_per_node * nr_numa_nodes() != g->p.nr_cpus);
> > - BUG_ON(!cpus_per_node);
> > -
> > ret = sched_getaffinity(0, sizeof(orig_mask), &orig_mask);
> > BUG_ON(ret);
> >
> > @@ -305,13 +302,15 @@ static cpu_set_t bind_to_node(int target_node)
> > for (cpu = 0; cpu < g->p.nr_cpus; cpu++)
> > CPU_SET(cpu, &mask);
> > } else {
> > - int cpu_start = (target_node + 0) * cpus_per_node;
> > - int cpu_stop = (target_node + 1) * cpus_per_node;
> > -
> > - BUG_ON(cpu_stop > g->p.nr_cpus);
> > + struct bitmask *cpumask = numa_allocate_cpumask();
> >
> > - for (cpu = cpu_start; cpu < cpu_stop; cpu++)
> > - CPU_SET(cpu, &mask);
> > + BUG_ON(!cpumask);
> > + if (!numa_node_to_cpus(target_node, cpumask)) {
> > + for (cpu = 0; cpu < (int)cpumask->size; cpu++) {
> > + if (numa_bitmask_isbitset(cpumask, cpu))
> > + CPU_SET(cpu, &mask);
> > + }
> > + }
>
> It seems you need to call numa_free_cpumask() for both functions.
Well, the whole approach to memory allocation is rather relaxed
troughout the code. I.e cpumasks do not get deallocated (*),
strdup() return values are not checked etc.
If it worth fixing all that then it would be a separate effort,
as far as I am concerned.
> Thanks
> Namhyung
>
> > }
> >
> > ret = sched_setaffinity(0, sizeof(mask), &mask);
> > --
> > 1.8.3.1
> >
next prev parent reply other threads:[~2020-08-11 8:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-10 6:21 [PATCH v2 0/3] perf bench numa: make possible testing on uneven and/or overlapping CPU ranges Alexander Gordeev
2020-08-10 6:21 ` [PATCH v2 1/3] perf bench numa: use numa_node_to_cpus() to bind tasks to nodes Alexander Gordeev
2020-08-11 7:26 ` Namhyung Kim
2020-08-11 8:11 ` Alexander Gordeev [this message]
2020-08-13 11:30 ` [PATCH v3 1/2] perf bench numa: fix cpumask memory leak in node_has_cpus() Alexander Gordeev
2020-08-13 12:06 ` Srikar Dronamraju
2020-08-13 13:03 ` Arnaldo Carvalho de Melo
2020-08-13 11:32 ` [PATCH v3 1/2] perf bench numa: use numa_node_to_cpus() to bind tasks to nodes Alexander Gordeev
2020-08-13 12:07 ` Srikar Dronamraju
2020-08-13 13:03 ` Arnaldo Carvalho de Melo
2020-08-10 6:21 ` [PATCH v2 2/3] perf bench numa: fix number of processes in "2x3-convergence" test Alexander Gordeev
2020-08-11 7:27 ` Namhyung Kim
2020-08-12 12:07 ` Arnaldo Carvalho de Melo
2020-08-10 6:22 ` [PATCH v2 3/3] perf bench numa: fix benchmark names Alexander Gordeev
2020-08-12 12:09 ` Arnaldo Carvalho de Melo
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=20200811081111.GA31614@oc3871087118.ibm.com \
--to=agordeev@linux.ibm.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=bala24@linux.vnet.ibm.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=naveen.n.rao@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=sathnaga@linux.vnet.ibm.com \
--cc=srikar@linux.vnet.ibm.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
all inboxes | Powered by JetHome®