lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 4 Jul 2013 22:52:18 +1000
From:	Michael Ellerman <michael@...erman.id.au>
To:	Vince Weaver <vince@...ter.net>
Cc:	Runzhen Wang <runzhen@...ux.vnet.ibm.com>,
	linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	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, Jun 25, 2013 at 12:46:42PM -0400, Vince Weaver wrote:
> 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?

I think there's another ~56K at runtime too, at least on my system where
each sysfs_dirent is 112 bytes.
 
> 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).

To be honest on Power7 systems we're not really bothered about ~100K,
that's less than two pages. But I agree with your point that it's
getting a bit silly.

Various folks have tried over the years to get alternative approaches
adopted (as I'm sure you know), and this has just ended up as the path
of least resistance.

> I'd like to repeat my unpopular position that we just link perf against 
> libpfm4 and keep event tables in userspace where they belong.

I don't think it even needs libpfm4, just some csv files in tools/perf
would do the trick.

Instead we have Google using gooda, which provides event decoding on top
of perf (via libpfm4). Andi Kleen at Intel has a tool that provides
event decoding on top of perf. Presumably Facebook do too? And at IBM
most folks still use oprofile, because it provides event decoding. 

cheers
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ