Messages in this thread | | | Date | Sat, 17 Jan 2009 10:53:39 +0100 | From | Andi Kleen <> | Subject | Re: [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.
| |