lkml.org 
[lkml]   [2009]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] Performance Counters for Linux, v4
On Sat, Jan 17, 2009 at 12:26:15PM +1100, Paul Mackerras wrote:
> Corey Ashford writes:
>
> > Over time, it seems clear that we will see multi-core processor designs
> > with increasingly large uncore/nest facilities, so this could become
> > more and more of an issue.
>
> Those nest events still get counted on counters that are in the CPU
> core, right?

Nope, Nehalem uncore counters are separate per socket. The uncore
has its own counters.

You can program them to interrupt some fixed CPU thread (but
it's not necessarily the thread who caused the event) or all CPU threads
on the socket.

I found these semantics quite hard to fit into oprofile too because
it also has too many per cpu events assumptions.

> So that sounds like they can be counted by one or more
> per-cpu perf_counter instances. That means that you're measuring them
> across all processes. Does it make any sense to try to attribute
> those events to individual processes? How would one do that?

You can't (except by forcing only a single thread to run on
the socket). The hardware doesn't know otherwise.

perfmon3 has a concept of counters which are system wide.
While that's also not a 100% match on a multi socket system
it's better than assigning it to some random CPU.

>
> Clearly, something has to know enough about the system topology to
> know how many counters are needed and which (virtual) cpus they should

Hmm you want to create new virtual cpus for this?

-Andi

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


\
 
 \ /
  Last update: 2009-01-17 10:41    [W:0.067 / U:0.548 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site