All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Ingo Molnar" <mingo@elte.hu>,
	"Frédéric Weisbecker" <fweisbec@gmail.com>,
	"Arnaldo Carvalho de Melo" <acme@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Q] perf, x86: should perf_event_x.c being compiled conditionally?
Date: Sat, 29 May 2010 17:19:31 +0400	[thread overview]
Message-ID: <20100529131931.GI5322@lenovo> (raw)
In-Reply-To: <20100529130254.GH5322@lenovo>

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

      reply	other threads:[~2010-05-29 13:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-28 21:35 [Q] perf, x86: should perf_event_x.c being compiled conditionally? Cyrill Gorcunov
2010-05-29  7:38 ` Peter Zijlstra
2010-05-29 13:02   ` Cyrill Gorcunov
2010-05-29 13:19     ` Cyrill Gorcunov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100529131931.GI5322@lenovo \
    --to=gorcunov@gmail.com \
    --cc=acme@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.