Re: [tip:perf/core] perf tools: Make Power7 events available forperf
From: Vince Weaver
Date: Fri Jul 26 2013 - 00:25:22 EST
On Thu, 25 Jul 2013, Michael Ellerman wrote:
> On Tue, Jul 23, 2013 at 05:38:21PM -0400, Vince Weaver wrote:
> Well cursing is what witches do, but if you need someone to swear a bit
> I can help you out, I am fuckin Australian after all.
I should point out the cursing is directed at the code in question and the
overall downhill direction in the perf_event interface, and not directed
at anyone personally.
I've been fighting a (losing) battle for the past 5 years trying to keep
event definitions out of the kernel, I just didn't expect defeat to come
so swiftly and so suddenly from an unexpected corner (the power arch).
> But there are ~50 generic events in Linux, and our PMU supports ~500.
> And our hardware designers use perf, and they need to test all 500
> events. And they're getting sick of using raw event codes.
And writing a small wrapper utility or patching perf is somehow harder
than sticking the whole mess in the kernel? I get annoyed having to look
up the value of ANSI color escape codes now and then, but I don't expect
to submit a patch for /sys/tty/colors/red to the kernel and have it
> > Abusing sysfs to waste 100k of non-swappable kernel memory on every
> > running Linux kernel everwhere
> It's great that you're so concerned about memory wastage on _powerpc_
It's a slippery slope.
> > Especially as it's likely this becomes stable ABI, and then you'll
> > promptly break it as has already happenend in the last kernel release
> > with the existing in-kernel powerpc events.
> You're becoming the boy who cried "ABI break" Vince. Yes we renamed one
> event, we knew full well that nothing was using it - not even trinity.
Yes, the interface has only been around for one kernel version and you've
already broken the ABI once. Not a very good track record. Event name
renaming is a lot bigger problem on x86 where certain vendors like to fuss
with the event names every 3 months or so.
trinity is just an example as the users tend to use -rc kernels and thus
find the breakages faster. The main problem is tools like PAPI that deal
with events in much more critical fashion, but the kernel devs don't
really seem to care much about HPC use cases.
> > I agree. So why is this patch in tip?
> Because acme picked it up before that thread got going.
once a patch gets into tip in my experience all public mailing list review
is done with, and the patch is more or less guaranteed to appear in the
next major release unless there's some sort of regression in linux-next.
Hence this last attempt to get people to discuss this. It will likely be
ignored, but at least I can feel like I tried.
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/