From: Ingo Molnar <mingo@kernel.org>
To: "Pádraig Brady" <P@draigBrady.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
jiri@gmail.com, Peter Zijlstra <a.p.zijlstra@chello.nl>,
Namhyung Kim <namhyung@kernel.org>,
David Ahern <dsahern@gmail.com>
Subject: Re: [PATCH 39/52] tools/perf/build: Automatically build in parallel, based on number of CPUs in the syst
Date: Tue, 8 Oct 2013 14:22:19 +0200 [thread overview]
Message-ID: <20131008122219.GA2678@gmail.com> (raw)
In-Reply-To: <5253F4D4.7070402@draigBrady.com>
* Pádraig Brady <P@draigBrady.com> wrote:
> On 10/08/2013 10:02 AM, Ingo Molnar wrote:
> > +ifeq ($(JOBS),)
> > + JOBS := $(shell grep -c ^processor /proc/cpuinfo 2>/dev/null)
>
> nproc is probably ubiquitous enough to use now
> (available since coreutils 8.1 (end of 2009))
>
> As well as being more concise, it will take
> account of offline CPUs etc.
/proc/cpuinfo takes account of offline CPUs as well:
# grep -c ^processor /proc/cpuinfo 2>/dev/null
16
# echo 0 > /sys/devices/system/cpu/cpu11/online
# grep -c ^processor /proc/cpuinfo 2>/dev/null
15
# echo 1 > /sys/devices/system/cpu/cpu11/online
# grep -c ^processor /proc/cpuinfo 2>/dev/null
16
But nproc is indeed a better choice:
1)
It is scheduler syscall based and will thus will work in limited
environments as well, for example when /proc is not mounted.
2)
It will also properly detect affinity-limited environments:
# taskset 1 nproc
1
3)
It is also faster than grepping /proc/cpuinfo:
# perf stat --null --repeat 100 nproc >/dev/null
Performance counter stats for 'nproc' (100 runs):
0.000652928 seconds time elapsed ( +- 0.53% )
versus:
# perf stat --null --repeat 100 grep -c ^processor /proc/cpuinfo >/dev/null
Performance counter stats for 'grep -c ^processor /proc/cpuinfo' (100 runs):
0.001037034 seconds time elapsed ( +- 0.32% )
so with 0.652 msecs versus 1.037 msecs it's about 60% faster than grep.
Thanks,
Ingo
prev parent reply other threads:[~2013-10-08 12:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-08 12:04 [PATCH 39/52] tools/perf/build: Automatically build in parallel, based on number of CPUs in the syst Pádraig Brady
2013-10-08 12:22 ` Ingo Molnar [this message]
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=20131008122219.GA2678@gmail.com \
--to=mingo@kernel.org \
--cc=P@draigBrady.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@infradead.org \
--cc=dsahern@gmail.com \
--cc=jiri@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=namhyung@kernel.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.