linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Jiri Olsa <jolsa@kernel.org>, lkml <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>, Andi Kleen <andi@firstfloor.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Kan Liang <kan.liang@intel.com>
Subject: Re: [PATCH] perf/x86/intel: Add proper condition to run sched_task callbacks
Date: Tue, 18 Jul 2017 11:29:32 +0200	[thread overview]
Message-ID: <20170718092932.GA26157@krava> (raw)
In-Reply-To: <20170718091444.afqdtgjijcztv2mn@hirez.programming.kicks-ass.net>

On Tue, Jul 18, 2017 at 11:14:44AM +0200, Peter Zijlstra wrote:
> On Mon, Jul 17, 2017 at 05:01:56PM +0200, Jiri Olsa wrote:
> > The x86 pmu currently uses the sched_task callback for 2 functions:
> >   - PEBS drain
> >   - save/restore LBR data
> > 
> > They are both triggered once the x86 pmu is registered with
> > perf_sched_cb_inc call (within pmu::add	callback), regardless
> > if there's actually any PEBS or LBR event configured on the cpu.
> 
> I don't understand. If we do pmu::add() we _are_ on the CPU.
> 
> So you're saying intel_pmu_pebs_{add,del}() are doing it wrong? So why
> not fix those?
> 
> > diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> > index aa62437d1aa1..1f66356d8122 100644
> > --- a/arch/x86/events/intel/core.c
> > +++ b/arch/x86/events/intel/core.c
> > @@ -3265,9 +3265,11 @@ static void intel_pmu_cpu_dying(int cpu)
> >  static void intel_pmu_sched_task(struct perf_event_context *ctx,
> >  				 bool sched_in)
> >  {
> > -	if (x86_pmu.pebs_active)
> > +	struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
> > +
> > +	if (intel_pmu_pebs_needs_sched_cb(cpuc))
> >  		intel_pmu_pebs_sched_task(ctx, sched_in);
> 
> So I'm confused, if we'd not need this, how come we're here in the first
> place?
> 

because we have 2 places using the same callback
  - PEBS drain for free running counters
  - LBR save/store

both of them called from intel_pmu_sched_task

so let's say PEBS drain setup the callback for the event,
but in the callback itself (intel_pmu_sched_task) we will
also run the code for LBR save/restore, which we did not
ask for, but the code in intel_pmu_sched_task does not
check for that

I'm adding conditions to recognize the work that needs
to be done in the callback

another option might be to add support for more x86_pmu::sched_task
callbacks, which might be cleaner

jirka

  reply	other threads:[~2017-07-18  9:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-17 15:01 [PATCH] perf/x86/intel: Add proper condition to run sched_task callbacks Jiri Olsa
2017-07-18  9:14 ` Peter Zijlstra
2017-07-18  9:29   ` Jiri Olsa [this message]
2017-07-18 12:37     ` Peter Zijlstra
2017-07-18 22:11       ` Jiri Olsa
2017-07-19  7:52       ` Jiri Olsa
2017-07-21  9:38         ` [tip:perf/urgent] " tip-bot for Jiri Olsa

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=20170718092932.GA26157@krava \
    --to=jolsa@redhat.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andi@firstfloor.org \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).