All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: "Liang, Kan" <kan.liang@linux.intel.com>
Cc: peterz@infradead.org, mingo@redhat.com, acme@kernel.org,
	linux-kernel@vger.kernel.org, tglx@linutronix.de,
	eranian@google.com, ak@linux.intel.com
Subject: Re: [RESEND PATCH V2 3/4] perf/x86/intel: drain PEBS buffer in event read
Date: Thu, 18 Jan 2018 10:49:48 +0100	[thread overview]
Message-ID: <20180118094948.GD5947@krava> (raw)
In-Reply-To: <662a138a-ba53-246f-9b6f-60c7dcbb3f5c@linux.intel.com>

On Tue, Jan 16, 2018 at 01:49:13PM -0500, Liang, Kan wrote:
> 
> 
> On 1/11/2018 10:45 AM, Jiri Olsa wrote:
> > On Thu, Jan 11, 2018 at 10:21:25AM -0500, Liang, Kan wrote:
> > 
> > SNIP
> > 
> > > > 
> > > > hum, but the PEBS drain is specific just for
> > > > PERF_X86_EVENT_AUTO_RELOAD events, right?
> > > 
> > > Accurately, PEBS drain is specific for PERF_X86_EVENT_FREERUNNING here.
> > > PERF_X86_EVENT_FREERUNNING event must be _AUTO_RELOAD event.
> > > But in some cases, _AUTO_RELOAD event cannot be _FREERUNNING event.
> > > 
> > > Only the event which is both _FREERUNNING and _AUTO_RELOAD need to do PEBS
> > > drain in _read().
> > > 
> > > So it does the check in intel_pmu_pebs_read()
> > > +	if (pebs_needs_sched_cb(cpuc))
> > > +		return intel_pmu_drain_pebs_buffer();
> > > 
> > > > 
> > > > wrt readability maybe you could add function like:
> > > 
> > > The existing function pebs_needs_sched_cb() can do the check.
> > > We just need to expose it, and also the intel_pmu_drain_pebs_buffer().
> > > 
> > > But to be honest, I still cannot see a reason for that.
> > > It could save a call to intel_pmu_pebs_read(), but _read() is not critical
> > > path. It doesn't save much.
> > 
> > hum, pmu->read is also called for PERF_SAMPLE_READ for sample,
> > check perf_output_read
> > 
> > for non sampling event you shouldn't be able to create PEBS
> > event, there's check in x86_pmu_hw_config
> > 
> > I agree it does not save much, it just confused me while
> > I was reading the code, like why is this needed for all
> > events with precise_ip
> > 
> 
> 
> Sorry for the late response.
> 
> How about the patch as below?
> The patch will be split into two patches in V3. One is to introduce
> intel_pmu_large_pebs_read, the other is to introduce intel_pmu_read_event.
> 
> Thanks,
> Kan
> 
> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index 731153a..1610a9d 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -2060,6 +2060,14 @@ static void intel_pmu_del_event(struct perf_event
> *event)
>  		intel_pmu_pebs_del(event);
>  }
> 
> +static void intel_pmu_read_event(struct perf_event *event)
> +{
> +	if (intel_pmu_large_pebs_read(event))
> +		return;

should this be 'if (!intel_pmu_large_pebs_read(event))'

but looks better for me without the precise_ip check

thanks,
jirka

  reply	other threads:[~2018-01-18  9:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-08 15:15 [RESEND PATCH V2 0/4] bug fix mmap read and rdpmc read in large PEBS kan.liang
2018-01-08 15:15 ` [RESEND PATCH V2 1/4] perf/x86/intel: fix event update for auto-reload kan.liang
2018-01-10 10:22   ` Jiri Olsa
2018-01-10 14:31     ` Liang, Kan
2018-01-11 10:54       ` Jiri Olsa
2018-01-24 12:26   ` Peter Zijlstra
2018-01-24 15:45     ` Liang, Kan
2018-01-08 15:15 ` [RESEND PATCH V2 2/4] perf/x86: introduce read function for x86_pmu kan.liang
2018-01-08 15:15 ` [RESEND PATCH V2 3/4] perf/x86/intel: drain PEBS buffer in event read kan.liang
2018-01-10 10:39   ` Jiri Olsa
2018-01-10 14:31     ` Liang, Kan
2018-01-11 11:10       ` Jiri Olsa
2018-01-11 15:21         ` Liang, Kan
2018-01-11 15:45           ` Jiri Olsa
2018-01-16 18:49             ` Liang, Kan
2018-01-18  9:49               ` Jiri Olsa [this message]
2018-01-18 13:30                 ` Liang, Kan
2018-01-18 14:05                   ` Jiri Olsa
2018-01-08 15:15 ` [RESEND PATCH V2 4/4] perf/x86: fix: disable userspace RDPMC usage for large PEBS kan.liang

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=20180118094948.GD5947@krava \
    --to=jolsa@redhat.com \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=eranian@google.com \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --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.