Re: [RFC] perf_events: support for uncore a.k.a. nest units

From: Corey Ashford
Date: Wed Jan 20 2010 - 14:29:31 EST




On 1/20/2010 1:35 AM, Andi Kleen wrote:
Yes, I agree. Also it's easy to construct a system design that doesn't
have a hierarchical topology. A simple example would be a cluster of 32
nodes, each of which is connected to its 31 neighbors. Perhaps for the

I doubt it's needed or useful to describe all details of an interconnect.


At this point, I don't see a need for that level of detail either.

If detailed distance information is needed a simple table like
the SLIT table exported by ACPI would seem easier to handle.


Thanks for the pointer. I didn't know about the ACPI SLIT and SRAT tables until your post. Having had a quick look at them, I don't think they'd be that helpful to us, at least at this point.

But at least some degree of locality (e.g. "local memory controller")
would make sense.

I think locality could be determined by looking at the device tree. For example, a memory controller for a particular processor chip would be a subdirectory of that chip.


purposes of just enumerating PMUs, a tree might be sufficient, but it's not
clear to me that it is mathematically sufficient for all topologies, not to
mention if it's intuitive enough to use. For example,
highly-interconnected components might require that PMU leaf nodes be
duplicated in multiple branches, i.e. PMU paths might not be unique in some
topologies.

We already have cyclical graphs in sysfs using symlinks. I'm not
sure they are all that easy to parse/handle, but at least they
can be described.

Good point.

--
Regards,

- Corey

Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
cjashfor@xxxxxxxxxx

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/