[Q] perf, x86: should perf_event_x.c being compiled conditionally?

[Q] perf, x86: should perf_event_x.c being compiled conditionally?

[Cyrill Gorcunov]

Hi,

while was building the kernel for pretty old laptop I've noticed
that perf_event_x.c depends on CONFIG_CPU_SUP_ only. So I'm somehow
confused. Should not some additional condition being used?

For example if a person have Core 2 or Nehalem machine, he will
definitely not need p6 and p4 events (yes, they are not _that_ big
in size, but anyway).

On the other hands distro builders would prefer to have all compiled in.

Not sure about what is the best way to resolve this, but perhaps I'm just
missing some key moment?

	-- Cyrill

Re: [Q] perf, x86: should perf_event_x.c being compiled conditionally?

[Peter Zijlstra]

On Sat, 2010-05-29 at 01:35 +0400, Cyrill Gorcunov wrote:
> Hi,
> 
> while was building the kernel for pretty old laptop I've noticed
> that perf_event_x.c depends on CONFIG_CPU_SUP_ only. So I'm somehow
> confused. Should not some additional condition being used?
> 
> For example if a person have Core 2 or Nehalem machine, he will
> definitely not need p6 and p4 events (yes, they are not _that_ big
> in size, but anyway).
> 
> On the other hands distro builders would prefer to have all compiled in.
> 
> Not sure about what is the best way to resolve this, but perhaps I'm just
> missing some key moment?

We had to split out on the CPU_SUP_* stuff because the AMD support
relies on symbols otherwise not present.

So fixing build dependencies is the main reason we have that.

If you want to extend it, feel free, but be sure to test the
full .config space ;-)

Re: [Q] perf, x86: should perf_event_x.c being compiled conditionally?

[Cyrill Gorcunov]

On Sat, May 29, 2010 at 09:38:57AM +0200, Peter Zijlstra wrote:
> On Sat, 2010-05-29 at 01:35 +0400, Cyrill Gorcunov wrote:
> > Hi,
> > 
> > while was building the kernel for pretty old laptop I've noticed
> > that perf_event_x.c depends on CONFIG_CPU_SUP_ only. So I'm somehow
> > confused. Should not some additional condition being used?
> > 
> > For example if a person have Core 2 or Nehalem machine, he will
> > definitely not need p6 and p4 events (yes, they are not _that_ big
> > in size, but anyway).
> > 
> > On the other hands distro builders would prefer to have all compiled in.
> > 
> > Not sure about what is the best way to resolve this, but perhaps I'm just
> > missing some key moment?
> 
> We had to split out on the CPU_SUP_* stuff because the AMD support
> relies on symbols otherwise not present.
> 
> So fixing build dependencies is the main reason we have that.
> 
> If you want to extend it, feel free, but be sure to test the
> full .config space ;-)
> 

Thanks for explanation. I guess we may have something like below.
Note that I didn't squeeze into *.c files, only Kconfig is touched
so that we get "Processor type and features" -> "Supported Perfomance
Events" menu. All entries are "Y" by default and depends on
PERF_EVENTS && CPU_SUP_INTEL (since we have this trick for Intel
cpus only at moment). Just an idea.

	-- Cyrill
---
 arch/x86/Kconfig.cpu      |    4 ++++
 arch/x86/Kconfig.cpu.perf |   31 +++++++++++++++++++++++++++++++
 2 files changed, 35 insertions(+)

Index: linux-2.6.git/arch/x86/Kconfig.cpu
=====================================================================
--- linux-2.6.git.orig/arch/x86/Kconfig.cpu
+++ linux-2.6.git/arch/x86/Kconfig.cpu
@@ -506,3 +506,7 @@ config CPU_SUP_UMC_32
 	  CPU might render the kernel unbootable.
 
 	  If unsure, say N.
+
+#
+# Performance event specifics
+source "arch/x86/Kconfig.cpu.perf"
Index: linux-2.6.git/arch/x86/Kconfig.cpu.perf
=====================================================================
--- /dev/null
+++ linux-2.6.git/arch/x86/Kconfig.cpu.perf
@@ -0,0 +1,31 @@
+if PERF_EVENTS && CPU_SUP_INTEL
+menu "Supported Performance Events"
+
+config PERF_EVENTS_INTEL
+	bool "Intel Architectural Performance Events"
+	default y
+	---help---
+	  Intel Architectural Performance Events (Architectural PerfMon version 2
+	  and later). Includes support for Core/Core2/Atom/Nehalem CPU families.
+
+	  If unsure say Y.
+
+config PERF_EVENTS_INTEL_NETBURST
+	bool "Netburst Performance Events"
+	default y
+	---help---
+	  Netburst family performance events (Pentium 4, old Xeons).
+
+	  If unsure say Y.
+
+config PERF_EVENTS_INTEL_P6
+	bool "P6 family Performance Events"
+	default y
+	---help---
+	  P6 family performance events (Pentium Pro, Pentium II,
+	  Pentium III, Pentium M).
+
+	  If unsure say Y.
+
+endmenu
+endif

Re: [Q] perf, x86: should perf_event_x.c being compiled conditionally?

[Cyrill Gorcunov]

On Sat, May 29, 2010 at 05:02:54PM +0400, Cyrill Gorcunov wrote:
> On Sat, May 29, 2010 at 09:38:57AM +0200, Peter Zijlstra wrote:
> > On Sat, 2010-05-29 at 01:35 +0400, Cyrill Gorcunov wrote:
> > > Hi,
> > > 
> > > while was building the kernel for pretty old laptop I've noticed
> > > that perf_event_x.c depends on CONFIG_CPU_SUP_ only. So I'm somehow
> > > confused. Should not some additional condition being used?
> > > 
> > > For example if a person have Core 2 or Nehalem machine, he will
> > > definitely not need p6 and p4 events (yes, they are not _that_ big
> > > in size, but anyway).
> > > 
> > > On the other hands distro builders would prefer to have all compiled in.
> > > 
> > > Not sure about what is the best way to resolve this, but perhaps I'm just
> > > missing some key moment?
> > 
> > We had to split out on the CPU_SUP_* stuff because the AMD support
> > relies on symbols otherwise not present.
> > 
> > So fixing build dependencies is the main reason we have that.
> > 
> > If you want to extend it, feel free, but be sure to test the
> > full .config space ;-)
> > 
> 
> Thanks for explanation. I guess we may have something like below.
> Note that I didn't squeeze into *.c files, only Kconfig is touched
> so that we get "Processor type and features" -> "Supported Perfomance
> Events" menu. All entries are "Y" by default and depends on
> PERF_EVENTS && CPU_SUP_INTEL (since we have this trick for Intel
> cpus only at moment). Just an idea.
> 

I'll take a more closer look (since we will need some placeholders
for unconditionally called funtions).

	-- Cyrill