mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org, Michael Neuling <mikey@neuling.org>
Subject: Re: [PATCH 2/2] perf tools: Cope with sparsely-numbered CPUs
Date: Tue, 15 Dec 2009 13:08:51 +0100	[thread overview]
Message-ID: <20091215120851.GA21780@elte.hu> (raw)
In-Reply-To: <20091215093437.GB18661@brick.ozlabs.ibm.com>


* Paul Mackerras <paulus@samba.org> wrote:

> For system-wide monitoring, the perf tools currently ask how many CPUs are 
> online, and then instantiate perf_events for CPUs 0 ... N-1.  This doesn't 
> work correctly when CPUs are numbered sparsely.  For example, a four-core 
> POWER6 in single-thread mode will have CPUs 0, 2, 4 and 6. The perf tools 
> will try to open counters on CPUs 0, 1, 2 and 3, and either fail with an 
> error message or silently ignore CPUs 4 and 6.
> 
> This fixes the problem by making perf stat, perf record and perf top
> create counters for increasing CPU numbers until they have a counter
> for each online CPU.  If the attempt to create a counter on a given
> CPU fails, we get an ENODEV error and we just move on to the next CPU.
> To avoid an infinite loop in case the number of online CPUs gets
> reduced while we are creating counters, we re-read the number of
> online CPUs when we fail to create a counter on some CPU.
> 
> Reported-by: Michael Neuling <mikey@neuling.org>
> Tested-by: Michael Neuling <mikey@neuling.org>
> Cc: stable@kernel.org
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
>  tools/perf/builtin-record.c |   36 ++++++++++++++++++++++++++++--------
>  tools/perf/builtin-stat.c   |   15 +++++++++++++--
>  tools/perf/builtin-top.c    |   27 +++++++++++++++++++--------
>  3 files changed, 60 insertions(+), 18 deletions(-)

nice fix!

The linecount bloat is a bit worrying though. I'm wondering, since we have 3 
loops now (and possibly more upcoming), wouldnt it be a cleaner fix to have 
some generic idiom of 'loop through all online cpus' somewhere in lib/*.c?

This would work better in the long run than spreading all the sysconf calls 
and special cases across all those callsites. (new tools will inevitably get 
it wrong as well)

As a practical matter we can commit your fix and do the cleanup/consolidation 
as a separate patch, to not hold up your fix (and to help fix/bisect any 
problems that would happen due to the consolidation) - as long as a 
consolidation patch is forthcoming as well.

Thanks,

	Ingo

  reply	other threads:[~2009-12-15 12:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-15  9:34 Paul Mackerras
2009-12-15 12:08 ` Ingo Molnar [this message]
2010-01-20  2:28   ` Anton Blanchard
2010-01-20  7:49     ` Ingo Molnar

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=20091215120851.GA21780@elte.hu \
    --to=mingo@elte.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikey@neuling.org \
    --cc=paulus@samba.org \
    --cc=peterz@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome