All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Jiri Olsa <jolsa@redhat.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 10:21:25 -0500	[thread overview]
Message-ID: <d4bba0d0-860a-a768-6bec-eb0fa8c33eee@linux.intel.com> (raw)
In-Reply-To: <20180111111001.GC31767@krava>



On 1/11/2018 6:10 AM, Jiri Olsa wrote:
> 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?

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.
Also, it has to expose two inline PEBS specific functions. I think 
exposing one PEBS generic function would be better here.

Thanks,
Kan
> 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 15:21 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 [this message]
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=d4bba0d0-860a-a768-6bec-eb0fa8c33eee@linux.intel.com \
    --to=kan.liang@linux.intel.com \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=eranian@google.com \
    --cc=jolsa@redhat.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.