[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <AANLkTi=9SYgy-bVvYVt5rb3G=yWJYYA4ym+SCDs-5o+y@mail.gmail.com>
Date: Tue, 23 Nov 2010 10:18:58 +0100
From: Stephane Eranian <eranian@...gle.com>
To: Andi Kleen <andi@...stfloor.org>
Cc: Lin Ming <ming.m.lin@...el.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Ingo Molnar <mingo@...e.hu>,
lkml <linux-kernel@...r.kernel.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Arjan van de Ven <arjan@...radead.org>
Subject: Re: [RFC PATCH 3/3 v2] perf: Update perf tool to monitor uncore events
On Sun, Nov 21, 2010 at 5:52 PM, Andi Kleen <andi@...stfloor.org> wrote:
>
>>>
>>> In fact I suspect uncore events are only really useful
>>> with "stat", but not with "top", or if they are used in top
>>> then the symbol reporting should be disabled.
>>>
>> I agree, uncore should only be used for counting on a
>> per-cpu basis. You can leave the perf tool as is, but
>
I meant one cpu per socket: perf stat -a -C 0 -e unc_clk_unhalted.
One could envision the tool picking one CPU per socket. It can
figure this out from the topology information in sysfs.
If you do perf stat -a -e unc_*, then you'll get into multiplexing very
quickly AND it is useless especially because auto aggregation will
yield bogus counts.
> I think you mean per socket base, right? per cpu (= cpu core thread)
> doesn't make sense for the uncore either.
>
> Per socket would need a new command line mode. The new mode should
> never report any symbols or processes, just events per socket.
>
> -Andi
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists