All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Mike Galbraith <efault@gmx.de>, Paul Mackerras <paulus@samba.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC PATCH 3/4] perf/core: Split up pinned and non pinned processing
Date: Tue, 10 Nov 2009 10:32:10 +0100	[thread overview]
Message-ID: <20091110093207.GA5255@nowhere> (raw)
In-Reply-To: <20091110051141.GD7897@elte.hu>

On Tue, Nov 10, 2009 at 06:11:41AM +0100, Ingo Molnar wrote:
> 
> * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> 
> > Split up pinned and non-pinned events processing in two helpers
> > so that it's more flexible to handle them seperately.
> 
> > +static void
> > +__perf_event_sched_in_volatile(struct perf_event_context *ctx,
> > +			       struct perf_cpu_context *cpuctx, int cpu)
> 
> Small naming suggestion: 'volatile' is a C keyword and rarely used 
> outside of that context in the kernel, which makes this function name a 
> bit confusing.
> 
> So instead of pinned/volatile, a pinned/flexible naming would be more 
> readable, i.e. __perf_event_sched_in_flexible() or so.


Right, also that makes it consistent with the hw-breakpoint constraints
naming.

 
> Also, most of the static functions in kernel/perf_event.c could lose 
> their perf_event_ prefix - we already know it's a perf thing, right? 
> That will shorten quite a few function names there.
> 
> These functions would turn into __sched_in_pinned()/__sched_in_flexible().
> 
> Agreed?


Totally.

I'll prepare a new iteration, thanks!


  reply	other threads:[~2009-11-10  9:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-08 20:13 [RFC PATCH 0/4] perf/core: Small event scheduling changes Frederic Weisbecker
2009-11-08 20:13 ` [RFC PATCH 1/4] perf/core: split context's event group list into pinned and non-pinned lists Frederic Weisbecker
2009-11-08 20:13 ` [RFC PATCH 2/4] perf/core: Optimize a bit rotate_ctx() Frederic Weisbecker
2009-11-08 20:13 ` [RFC PATCH 3/4] perf/core: Split up pinned and non pinned processing Frederic Weisbecker
2009-11-10  5:11   ` Ingo Molnar
2009-11-10  9:32     ` Frederic Weisbecker [this message]
2009-11-08 20:13 ` [RFC PATCH 4/4] perf/core: Schedule every pinned events before the the non-pinned Frederic Weisbecker
2009-11-10 10:10   ` Peter Zijlstra
2009-11-10 10:34     ` Frederic Weisbecker
2009-11-10  5:13 ` [RFC PATCH 0/4] perf/core: Small event scheduling changes Ingo Molnar
2009-11-10  9:41   ` Frederic Weisbecker
2009-11-10  9:47     ` Frederic Weisbecker

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=20091110093207.GA5255@nowhere \
    --to=fweisbec@gmail.com \
    --cc=acme@redhat.com \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /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.