linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* perf uncore behavior
@ 2015-05-01 20:55 Chris Freehill
  2015-05-02  1:40 ` Andi Kleen
  0 siblings, 1 reply; 4+ messages in thread
From: Chris Freehill @ 2015-05-01 20:55 UTC (permalink / raw)
  To: linux-perf-users

Hi,

I'm trying to get clarification on the meaning of the results perf
gives for uncore events, depending on the options.

Here are some examples:

1. $ perf stat -a -e "uncore_cbox_0/clockticks/" sleep 1

2. $ perf stat  -e "uncore_cbox_0/clockticks/" sleep 1

3. $ perf stat -a -C0 -e "uncore_cbox_0/clockticks/" sleep 1

It appears #2 is not supported. If it was supported, I would take it
to mean the number of uncore events counted while the process was
active, regardless of which processor it was running on. Right?  Is
there any reason it's not implemented (for example it's nonsensical)
or it just has been tackled yet?

Are 1 and 3 effectively the same, since uncore events are not specific
to a core? I would think they would be the same. If not, what is the
difference?

thanks,
Chris

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: perf uncore behavior
  2015-05-01 20:55 perf uncore behavior Chris Freehill
@ 2015-05-02  1:40 ` Andi Kleen
  2015-05-02  2:31   ` Chris Freehill
  0 siblings, 1 reply; 4+ messages in thread
From: Andi Kleen @ 2015-05-02  1:40 UTC (permalink / raw)
  To: Chris Freehill; +Cc: linux-perf-users

Chris Freehill <cfreehill@utexas.edu> writes:
>
> Here are some examples:
>
> 1. $ perf stat -a -e "uncore_cbox_0/clockticks/" sleep 1
>
> 2. $ perf stat  -e "uncore_cbox_0/clockticks/" sleep 1
>
> 3. $ perf stat -a -C0 -e "uncore_cbox_0/clockticks/" sleep 1
>
> It appears #2 is not supported. If it was supported, I would take it
> to mean the number of uncore events counted while the process was
> active, regardless of which processor it was running on. Right?  Is
> there any reason it's not implemented (for example it's nonsensical)
> or it just has been tackled yet?

It's non sensical.  Uncore does not support per process measurements.

> Are 1 and 3 effectively the same, since uncore events are not specific
> to a core? I would think they would be the same. If not, what is the
> difference?

1. will sum up events from all sockets/nodes.
3. will only print from the socket/node associated with CPU 0.

-andi

-- 
ak@linux.intel.com -- Speaking for myself only

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: perf uncore behavior
  2015-05-02  1:40 ` Andi Kleen
@ 2015-05-02  2:31   ` Chris Freehill
  2015-05-02 12:16     ` Andi Kleen
  0 siblings, 1 reply; 4+ messages in thread
From: Chris Freehill @ 2015-05-02  2:31 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-perf-users

Thanks Andi.

A follow up...can  you define what  "sockets/nodes" means in this
context? What is the relationship between sockets/nodes and CPU's.
What is the distinction? For core events, they would be the same,
right? Could you give an example of what "-a" would sum up when we are
talking about uncore events?

I think my main confusion is an assumption (up to now, anyway) that
there is only one set of uncore events, for the multicore device, so
it wouldn't make sense to sum up anything. For core events, my
understanding is that with no "-C<core id>" specified, perf sums up
the core event counts and presents this as output. For uncore, the
events are not per-core, so I'm not sure how to interpret that "sum".

Chris

On Fri, May 1, 2015 at 8:40 PM, Andi Kleen <andi@firstfloor.org> wrote:
> Chris Freehill <cfreehill@utexas.edu> writes:
>>
>> Here are some examples:
>>
>> 1. $ perf stat -a -e "uncore_cbox_0/clockticks/" sleep 1
>>
>> 2. $ perf stat  -e "uncore_cbox_0/clockticks/" sleep 1
>>
>> 3. $ perf stat -a -C0 -e "uncore_cbox_0/clockticks/" sleep 1
>>
>> It appears #2 is not supported. If it was supported, I would take it
>> to mean the number of uncore events counted while the process was
>> active, regardless of which processor it was running on. Right?  Is
>> there any reason it's not implemented (for example it's nonsensical)
>> or it just has been tackled yet?
>
> It's non sensical.  Uncore does not support per process measurements.
>
>> Are 1 and 3 effectively the same, since uncore events are not specific
>> to a core? I would think they would be the same. If not, what is the
>> difference?
>
> 1. will sum up events from all sockets/nodes.
> 3. will only print from the socket/node associated with CPU 0.
>
> -andi
>
> --
> ak@linux.intel.com -- Speaking for myself only

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: perf uncore behavior
  2015-05-02  2:31   ` Chris Freehill
@ 2015-05-02 12:16     ` Andi Kleen
  0 siblings, 0 replies; 4+ messages in thread
From: Andi Kleen @ 2015-05-02 12:16 UTC (permalink / raw)
  To: Chris Freehill; +Cc: Andi Kleen, linux-perf-users

On Fri, May 01, 2015 at 09:31:58PM -0500, Chris Freehill wrote:
> A follow up...can  you define what  "sockets/nodes" means in this
> context? What is the relationship between sockets/nodes and CPU's.

In Linux terminology a CPU is a logical CPU thread. A socket
is a physical chip. 

> What is the distinction? For core events, they would be the same,
> right? Could you give an example of what "-a" would sum up when we are
> talking about uncore events?

It sums up events from all sockets

> 
> I think my main confusion is an assumption (up to now, anyway) that
> there is only one set of uncore events, for the multicore device, so
> it wouldn't make sense to sum up anything. 

There is one set per socket (or rather chip, if you talk about an
multi-chip-module)

> For core events, my
> understanding is that with no "-C<core id>" specified, perf sums up
> the core event counts and presents this as output. For uncore, the
> events are not per-core, so I'm not sure how to interpret that "sum".

It's the sum of all cores on that socket.

-Andi

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-05-02 12:16 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-05-01 20:55 perf uncore behavior Chris Freehill
2015-05-02  1:40 ` Andi Kleen
2015-05-02  2:31   ` Chris Freehill
2015-05-02 12:16     ` Andi Kleen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).