[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1306251240440.25443@pianoman.cluster.toy>
Date: Tue, 25 Jun 2013 12:46:42 -0400 (EDT)
From: Vince Weaver <vince@...ter.net>
To: Runzhen Wang <runzhen@...ux.vnet.ibm.com>
cc: linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
michael@...erman.id.au, paulus@...ba.org, acme@...hat.com,
Peter Zijlstra <peterz@...radead.org>, mingo@...nel.org,
vincent.weaver@...ne.edu, Stephane Eranian <eranian@...gle.com>,
sukadev@...ux.vnet.ibm.com, xiaoguangrong@...ux.vnet.ibm.com
Subject: Re: [PATCH v2 2/2] perf tools: Make Power7 events available for
perf
On Tue, 25 Jun 2013, Runzhen Wang wrote:
> This patch makes all the POWER7 events available in sysfs.
>
> ...
>
> $ size arch/powerpc/perf/power7-pmu.o
> text data bss dec hex filename
> 3073 2720 0 5793 16a1 arch/powerpc/perf/power7-pmu.o
>
> and after the patch is applied, it is:
>
> $ size arch/powerpc/perf/power7-pmu.o
> text data bss dec hex filename
> 15950 31112 0 47062 b7d6 arch/powerpc/perf/power7-pmu.o
So if I'm reading this right, there's 45k of overhead for just one cpu
type?
What happens if we do this on x86?
If we have similar for p6/p4/core2/nehalem/ivb/snb/amd10h/amd15h/amd16h/knb
that's 450k of event defintions in the kernel. And may I remind everyone
that you can't compile perf_event support as a module, nor can you
unconfigure it on x86 (it's always built in, no option to disable).
I'd like to repeat my unpopular position that we just link perf against
libpfm4 and keep event tables in userspace where they belong.
Vince
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists