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, 11 Jan 2018 12:10:01 +0100	[thread overview]
Message-ID: <20180111111001.GC31767@krava> (raw)
In-Reply-To: <6bb19af0-24e5-d711-cb6f-139eb99253c1@linux.intel.com>

On Wed, Jan 10, 2018 at 09:31:56AM -0500, Liang, Kan wrote:
> 
> 
> On 1/10/2018 5:39 AM, Jiri Olsa wrote:
> > On Mon, Jan 08, 2018 at 07:15:15AM -0800, kan.liang@intel.com wrote:
> > > From: Kan Liang <kan.liang@linux.intel.com>
> > > 
> > > When the PEBS interrupt threshold is larger than one, there is no way to
> > > get exact auto-reload times and value needed for event update unless
> > > flush the PEBS buffer.
> > > 
> > > Drain the PEBS buffer in event read when large PEBS is enabled.
> > > 
> > > For the threshold is one, even auto-reload is enabled, it doesn't need
> > > to be specially handled. Because auto-reload is only effect when event
> > > overflow. There is no overflow in event read.
> > > 
> > > Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
> > > ---
> > >   arch/x86/events/intel/core.c |  9 +++++++++
> > >   arch/x86/events/intel/ds.c   | 10 ++++++++++
> > >   arch/x86/events/perf_event.h |  2 ++
> > >   3 files changed, 21 insertions(+)
> > > 
> > > diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> > > index 09c26a4..bdc35f8 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 (event->attr.precise_ip)
> > > +		return intel_pmu_pebs_read(event);
> > 
> > check for (event->hw.flags & PERF_X86_EVENT_AUTO_RELOAD)
> > would be more accurate?
> > 
> 
> It will narrow down the events.
> But considering the readability, I think it would be better to use
> precise_ip.The exposed functions in ds.c should be generic functions for all
> PEBS events, not specific case.
> I think _AUTO_RELOAD looks too specific.

hum, but the PEBS drain is specific just for
PERF_X86_EVENT_AUTO_RELOAD events, right?

wrt readability maybe you could add function like:
bool pebs_drain_before_read(struct perf_event *event)
{
	return event->hw.flags & PERF_X86_EVENT_AUTO_RELOAD;
}

thanks,
jirka

  reply	other threads:[~2018-01-11 11:10 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 [this message]
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
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=20180111111001.GC31767@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.