All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Borislav Petkov <bp@amd64.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Ingo Molnar <mingo@elte.hu>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] perf: Carve out cgroup-related code
Date: Thu, 12 May 2011 16:31:52 +0200	[thread overview]
Message-ID: <20110512143148.GB7410@nowhere> (raw)
In-Reply-To: <20110512101839.GA17731@aftab>

On Thu, May 12, 2011 at 12:18:39PM +0200, Borislav Petkov wrote:
> On Thu, May 12, 2011 at 04:51:17AM -0400, Peter Zijlstra wrote:
> > On Wed, 2011-05-11 at 19:09 +0200, Borislav Petkov wrote:
> > 
> > I can't really say I like this move stuff into perf_event.h and then
> > move it out again dance. Makes it exceedingly hard for me to tell wth
> > actually happened.
> > 
> > >  include/linux/perf_event.h |  132 --------------------------------------------
> > 
> > Compared with:
> > 
> >  include/linux/perf_event.h |  126 +++++++++++-
> >  include/linux/perf_event.h |    7 +-
> > 
> > Its very hard to tell if this undoes the exact damage you did earlier.
> 
> The right thing to do would be to redo the patches again with internal.h
> in mind.
> 
> > >  kernel/events/callchain.c  |    3 +
> > >  kernel/events/cgroup.c     |    2 +
> > >  kernel/events/core.c       |    2 +
> > >  kernel/events/internal.h   |  129 +++++++++++++++++++++++++++++++++++++++++++
> > >  5 files changed, 136 insertions(+), 132 deletions(-)
> > >  create mode 100644 kernel/events/internal.h
> > > 
> > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > > index 7978850..6b25452 100644
> > > --- a/include/linux/perf_event.h
> > > +++ b/include/linux/perf_event.h
> > > @@ -963,7 +963,6 @@ enum event_type_t {
> > >  #ifdef CONFIG_PERF_EVENTS
> > >  extern struct list_head pmus;
> > >  extern int perf_pmu_register(struct pmu *pmu, char *name, int type);
> > > -extern void perf_pmu_unregister(struct pmu *pmu);
> > 
> > That just doesn't make any sense. If we publish one side of the API we
> > should also publish the other side.
> 
> Fair enough. It was unused, therefore I removed it.
> 
> > >  extern int perf_num_counters(void);
> > >  extern const char *perf_pmu_name(void);
> > > @@ -985,8 +984,6 @@ perf_event_create_kernel_counter(struct perf_event_attr *attr,
> > >                                 int cpu,
> > >                                 struct task_struct *task,
> > >                                 perf_overflow_handler_t callback);
> > > -extern u64 perf_event_read_value(struct perf_event *event,
> > > -                                u64 *enabled, u64 *running);
> > 
> > While not used, that is a valid part of the API.
> 
> Yep, ditto.
> 
> > >  
> > >  struct perf_sample_data {
> > >         u64                             type;
> > > @@ -1152,60 +1149,10 @@ extern int perf_output_begin(struct perf_output_handle *handle,
> > >                              struct perf_event *event, unsigned int size,
> > >                              int nmi, int sample);
> > >  extern void perf_output_end(struct perf_output_handle *handle);
> > > -extern void perf_output_copy(struct perf_output_handle *handle,
> > > -                            const void *buf, unsigned int len);
> > 
> > idem
> > 
> > >  extern int perf_swevent_get_recursion_context(void);
> > > -extern void perf_swevent_put_recursion_context(int rctx);
> > 
> > Again, creating asymmetry. 
> 
> Ok, I won't be able to redo the patches before Mo. due to travel. Also,
> I think that you should do the splitting, as I suggested so at the
> beginning!

I can take it if you want. I'm currently splitting the buffer
part so I can try to relay the rest as well :)

  reply	other threads:[~2011-05-12 14:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-11 12:11 [RFC PATCH] perf: Carve out cgroup-related code Borislav Petkov
2011-05-11 13:46 ` Peter Zijlstra
2011-05-11 14:00   ` Ingo Molnar
2011-05-11 14:02   ` Borislav Petkov
2011-05-11 14:13     ` Ingo Molnar
2011-05-11 14:31       ` Borislav Petkov
2011-05-11 15:21         ` Ingo Molnar
2011-05-11 17:09           ` Borislav Petkov
2011-05-12  8:51             ` Peter Zijlstra
2011-05-12  8:54               ` Peter Zijlstra
2011-05-12 10:18               ` Borislav Petkov
2011-05-12 14:31                 ` Frederic Weisbecker [this message]
2011-05-12 15:13                   ` Lin Ming
2011-05-14  8:44                   ` Borislav Petkov
2011-05-14 13:02                     ` Frederic Weisbecker
2011-05-12 10:36             ` Ingo Molnar
2011-05-12 10:54               ` Borislav Petkov
2011-05-12 11:03                 ` Ingo Molnar

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=20110512143148.GB7410@nowhere \
    --to=fweisbec@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=bp@amd64.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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.