mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: mingo@redhat.com, acme@kernel.org, namhyung@kernel.org,
	irogers@google.com, linux-kernel@vger.kernel.org,
	linux-perf-users@vger.kernel.org, ak@linux.intel.com,
	eranian@google.com
Subject: Re: [PATCH V5 4/4] perf/x86/intel: Support PEBS counters snapshotting
Date: Tue, 17 Dec 2024 15:59:59 -0500	[thread overview]
Message-ID: <6467b30e-26a5-444c-bc20-5be7690e1e4c@linux.intel.com> (raw)
In-Reply-To: <20241217202919.GG11133@noisy.programming.kicks-ass.net>



On 2024-12-17 3:29 p.m., Peter Zijlstra wrote:
> On Tue, Dec 17, 2024 at 12:45:56PM -0500, Liang, Kan wrote:
> 
> 
>>> Why can't you use something like the below -- that gives you a count
>>> value matching the pmc value you put in, as long as it is 'near' the
>>> current value.
>>>
>>> ---
>>> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
>>> index 8f218ac0d445..3cf8b4f2b2c1 100644
>>> --- a/arch/x86/events/core.c
>>> +++ b/arch/x86/events/core.c
>>> @@ -154,6 +154,26 @@ u64 x86_perf_event_update(struct perf_event *event)
>>>  	return new_raw_count;
>>>  }
>>>  
>>> +u64 x86_perf_event_pmc_to_count(struct perf_event *event, u64 pmc)
>>> +{
>>> +	struct hw_perf_event *hwc = &event->hw;
>>> +	int shift = 64 - x86_pmu.cntval_bits;
>>> +	u64 prev_pmc, prev_count;
>>> +	u64 delta;
>>> +
>>> +	do {
>>> +		prev_pmc = local64_read(&hwc->prev_count);
>>> +		barrier();
>>> +		prev_count = local64_read(&event->count);
>>> +		barrier();
>>> +	} while (prev_pmc != local64_read(&hwc->prev_count));
>>
>> Is the "while()" to handle PMI? But there should be no PMI, since the
>> PMU has been disabled when draining the PEBS buffer.
> 
> Perhaps not in your case, but this way the function is more widely
> usable.
> 
>> diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
>> index e06ac9a3cdf8..7f0b850f7277 100644
>> --- a/arch/x86/events/intel/ds.c
>> +++ b/arch/x86/events/intel/ds.c
>> @@ -1969,6 +1969,23 @@ static void adaptive_pebs_save_regs(struct
>> pt_regs *regs,
>>
>>  #define PEBS_LATENCY_MASK			0xffff
>>
>> +void intel_perf_event_pmc_to_count(struct perf_event *event, u64 pmc)
>> +{
>> +	struct hw_perf_event *hwc = &event->hw;
>> +	int shift = 64 - x86_pmu.cntval_bits;
>> +	u64 prev_pmc;
>> +	u64 delta;
>> +
>> +	prev_pmc = local64_read(&hwc->prev_count);
>> +
>> +	delta = (pmc << shift) - (prev_pmc << shift);
>> +	delta >>= shift;
>> +
>> +	local64_add(delta, &event->count);
>> +	local64_sub(delta, &hwc->period_left);
>> +	local64_set(&hwc->prev_count, pmc);
>> +}
> 
> This seems very fragile, at least keep the same store order and assert
> you're in NMI/PMI context.

Sure, I will keep the store order.
You mean assert when there may be an unexpected NMI for the normal drain
case, right? I think we can check if the PMU is disabled as below.

@@ -1974,12 +1974,15 @@ static void intel_perf_event_pmc_to_count(struct
perf_event *event, u64 pmc)
 	int shift = 64 - x86_pmu.cntval_bits;
 	u64 delta;

+	/* Only read update the count when the PMU is disabled */
+	WARN_ON(this_cpu_read(cpu_hw_events.enabled));
+	local64_set(&hwc->prev_count, pmc);
+
 	delta = (pmc << shift) - (prev_pmc << shift);
 	delta >>= shift;

 	local64_add(delta, &event->count);
 	local64_sub(delta, &hwc->period_left);
-	local64_set(&hwc->prev_count, pmc);
 }

Thanks,
Kan



  reply	other threads:[~2024-12-17 21:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-16 20:45 [PATCH V5 1/4] perf/x86/intel/ds: Add PEBS format 6 kan.liang
2024-12-16 20:45 ` [PATCH V5 2/4] perf/x86: Extend event update interface kan.liang
2024-12-16 20:45 ` [PATCH V5 3/4] perf: Extend perf_output_read kan.liang
2024-12-16 20:45 ` [PATCH V5 4/4] perf/x86/intel: Support PEBS counters snapshotting kan.liang
2024-12-17 13:37   ` Peter Zijlstra
2024-12-17 17:45     ` Liang, Kan
2024-12-17 20:29       ` Peter Zijlstra
2024-12-17 20:59         ` Liang, Kan [this message]
2024-12-18  8:24       ` Peter Zijlstra
2024-12-18 14:52         ` Liang, Kan
2024-12-24  9:46 ` [tip: perf/urgent] perf/x86/intel/ds: Add PEBS format 6 tip-bot2 for 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=6467b30e-26a5-444c-bc20-5be7690e1e4c@linux.intel.com \
    --to=kan.liang@linux.intel.com \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@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

all inboxes | Powered by JetHome®