Hi, Anybody from AMD or formerly @ AMD care to submit a libpfm4 patch to add the Fam15th NB events?
I'd like to avoid having to type them in manually. Thanks. On Sun, Nov 11, 2012 at 7:44 PM, Jacob Shin <jacob.s...@amd.com> wrote: > On Sat, Nov 10, 2012 at 12:50:27PM +0100, Robert Richter wrote: >> On 09.11.12 19:01:34, Jacob Shin wrote: >> > The following patchset enables 4 additional performance counters in >> > AMD family 15h processors that counts northbridge events -- such as >> > DRAM accesses. >> > >> > This patchset is based on previous work done by Robert Richter >> > <r...@kernel.org> : >> > >> > https://lkml.org/lkml/2012/6/19/324 >> >> The original patch set of this is here (a rebased version): >> >> >> http://git.kernel.org/?p=linux/kernel/git/rric/oprofile.git;a=shortlog;h=refs/heads/perf-nb >> >> This code was tested in detail. >> >> > The main differences are: >> > >> > - The northbridge counters are indexed contiguously right above the >> > core performance counters. >> > >> > - MSR address offset calculations are moved to architecture specific >> > files. >> > >> > - Interrups are set up to be delivered only to a single core. >> >> So I rather suggest to make delta patches on top of my patches. > > Okay, if we have to, I can rework my patches on top of that, as long > as the end result looks something like I'm suggesting above. Because > in an upcoming processor family, there is no core performance counter > extensions, but we do have northbridge performance counters. Meaning > the counter address base would be c0010000 and northbridge counters > live in c0010240, being 0x240 apart, we could make counter masks work > but that testng awful alot of 0's for every address offset calculation > . > >> >> Peter's main concerns were that my patch set is not in the >> Intel-uncore style. I started reworking this but was not able to >> finish my work. This concerns still exist. > > Right, I considered this too, and still, I agree with you Robert that > it makes more sense to just extend AMD's x86 PMU. > > 1. Because the hardware interface -- register bit fields, are alost > identical > > 2. Because the interrupt delivery mechanism is also identical -- > delivered via same APIC interrupt vector. > > I think my proposed patchset on top of current Linus's tree is pretty > minimal, and is isolated to AMD so it should be easier to swallow. > > Peter, could you take a look at the patchset and if you still prefer > a intel uncore like implementation? > >> >> Due to the current situation I would rather prefer to create a >> tip:perf/amd-nb branch that includes my patches and then add all >> further necessary steps for mainline acceptance on top of it. > > Okay, Peter, let me know if this is a route to go, and I'll generate > my patchset on top of that. > > Thanks, > > -Jacob > >> >> Thanks, >> >> -Robert >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
