linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Adrian Hunter <adrian.hunter@intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Thomas Richter <tmricht@linux.ibm.com>,
	Hendrik Brueckner <brueckner@linux.ibm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Mike Leach <mike.leach@linaro.org>,
	James Clark <james.clark@arm.com>,
	coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
	Yicong Yang <yangyicong@hisilicon.com>,
	Jonathan Cameron <jonathan.cameron@huawei.com>,
	Will Deacon <will@kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
	Ian Rogers <irogers@google.com>, Andi Kleen <ak@linux.intel.com>,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org
Subject: Re: [PATCH V8 02/12] perf/x86/intel/pt: Add support for pause / resume
Date: Thu, 11 Jul 2024 16:35:00 +0300	[thread overview]
Message-ID: <0c59b36f-9b83-475f-b3b2-7fe3649412f4@intel.com> (raw)
In-Reply-To: <20240701104659.GB20127@noisy.programming.kicks-ass.net>

On 1/07/24 13:46, Peter Zijlstra wrote:
> On Fri, Jun 28, 2024 at 09:51:01AM +0300, Adrian Hunter wrote:
> 
>> @@ -534,7 +537,20 @@ static void pt_config(struct perf_event *event)
>>  	reg |= (event->attr.config & PT_CONFIG_MASK);
>>  
>>  	event->hw.config = reg;
>> +
>> +	/*
>> +	 * Allow resume before starting so as not to overwrite a value set by a
>> +	 * PMI.
>> +	 */
>> +	WRITE_ONCE(pt->resume_allowed, 1);
> 	barrier();
>>  	pt_config_start(event);
> 	barrier();
>> +	/*
>> +	 * Allow pause after starting so its pt_config_stop() doesn't race with
>> +	 * pt_config_start().
>> +	 */
>> +	WRITE_ONCE(pt->pause_allowed, 1);
> 
> IIRC you need those barrier()s, because if the compiler 'helpfully'
> inlines the static pt_config_start(), you loose your sequence point and
> things can get re-ordered. WRITE_ONCE() only ensures the store is whole
> and ordered against other volatile ops, but not against much else.

Yes barriers are needed.  gcc even says:

	...an implementation is free to reorder and combine volatile
	accesses that occur between sequence points...

	Accesses to non-volatile objects are not ordered with respect
	to volatile accesses.

	https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html

> 
>>  }
>>  
>>  static void pt_config_stop(struct perf_event *event)
>> @@ -1511,6 +1527,7 @@ void intel_pt_interrupt(void)
>>  		buf = perf_aux_output_begin(&pt->handle, event);
>>  		if (!buf) {
>>  			event->hw.state = PERF_HES_STOPPED;
>> +			pt->resume_allowed = 0;
>>  			return;
>>  		}
>>  
>> @@ -1519,6 +1536,7 @@ void intel_pt_interrupt(void)
>>  		ret = pt_buffer_reset_markers(buf, &pt->handle);
>>  		if (ret) {
>>  			perf_aux_output_end(&pt->handle, 0);
>> +			pt->resume_allowed = 0;
>>  			return;
>>  		}
>>  
> 
> Above you WRITE_ONCE() on ->resume_allowed, here you do not. Some *SAN
> thing or other is bound to get upset about things like that.
> 
>> @@ -1573,6 +1591,26 @@ static void pt_event_start(struct perf_event *event, int mode)
>>  	struct pt *pt = this_cpu_ptr(&pt_ctx);
>>  	struct pt_buffer *buf;
>>  
>> +	if (mode & PERF_EF_RESUME) {
>> +		if (READ_ONCE(pt->resume_allowed)) {
> 
> At this point I seem to have lost the plot, how do ->resume_allowed and
> ->aux_paused interact?

This is assuming there is no guaranteed order that events
in the group are started / stopped, so there is a need to
protect against pt being resumed when it is not yet configured,
or when it is in the process of being stopped.

Updates to event->hw.state don't happen at quite the right
places to be used instead, and the needs of resume are slightly
different to pause.

resume_allowed means pt is configured and so ->start(PERF_EF_RESUME)
can actually safely start pt. aux_paused is separate and takes
effect when there is a regular start.

> 
>> +			u64 status;
>> +
>> +			/*
>> +			 * Only if the trace is not active and the error and
>> +			 * stopped bits are clear, is it safe to start, but a
>> +			 * PMI might have just cleared these, so resume_allowed
>> +			 * must be checked again also.
>> +			 */
>> +			rdmsrl(MSR_IA32_RTIT_STATUS, status);
>> +			if (!(status & (RTIT_STATUS_TRIGGEREN |
>> +					RTIT_STATUS_ERROR |
>> +					RTIT_STATUS_STOPPED)) &&
>> +			   READ_ONCE(pt->resume_allowed))
>> +				pt_config_start(event);
>> +		}
>> +		return;
>> +	}
>> +
>>  	buf = perf_aux_output_begin(&pt->handle, event);
>>  	if (!buf)
>>  		goto fail_stop;
>> @@ -1601,6 +1639,16 @@ static void pt_event_stop(struct perf_event *event, int mode)
>>  {
>>  	struct pt *pt = this_cpu_ptr(&pt_ctx);
>>  
>> +	if (mode & PERF_EF_PAUSE) {
>> +		if (READ_ONCE(pt->pause_allowed))
>> +			pt_config_stop(event);
>> +		return;
>> +	}
>> +
>> +	/* Protect against racing */
> 
> No F1 cars allowed? Sure the comment can elucidate the reader as to what
> actual race one is concerned about, no?

Yeah this needs more comments.

> 
>> +	WRITE_ONCE(pt->pause_allowed, 0);
>> +	WRITE_ONCE(pt->resume_allowed, 0);
>> +
>>  	/*
>>  	 * Protect against the PMI racing with disabling wrmsr,
>>  	 * see comment in intel_pt_interrupt().
>> @@ -1659,8 +1707,12 @@ static long pt_event_snapshot_aux(struct perf_event *event,
>>  	/*
>>  	 * Here, handle_nmi tells us if the tracing is on
>>  	 */
>> -	if (READ_ONCE(pt->handle_nmi))
>> +	if (READ_ONCE(pt->handle_nmi)) {
>> +		/* Protect against racing */
>> +		WRITE_ONCE(pt->pause_allowed, 0);
>> +		WRITE_ONCE(pt->resume_allowed, 0);
> 
> barrier()?
> 
>>  		pt_config_stop(event);
>> +	}
>>  
>>  	pt_read_offset(buf);
>>  	pt_update_head(pt);
>> @@ -1677,8 +1729,11 @@ static long pt_event_snapshot_aux(struct perf_event *event,
>>  	 * Compiler barrier not needed as we couldn't have been
>>  	 * preempted by anything that touches pt->handle_nmi.
>>  	 */
>> -	if (pt->handle_nmi)
>> +	if (pt->handle_nmi) {
>> +		WRITE_ONCE(pt->resume_allowed, 1);
>>  		pt_config_start(event);
>> +		WRITE_ONCE(pt->pause_allowed, 1);
> 
> barrier() went missing again?
> 
>> +	}
>>  
>>  	return ret;
>>  }


  reply	other threads:[~2024-07-11 13:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-28  6:50 [PATCH V8 00/12] perf/core: Add ability for an event to "pause" or "resume" AUX area tracing Adrian Hunter
2024-06-28  6:51 ` [PATCH V8 01/12] perf/core: Add aux_pause, aux_resume, aux_start_paused Adrian Hunter
2024-07-01 10:26   ` Peter Zijlstra
2024-07-11 10:42     ` Adrian Hunter
2024-07-11 11:51       ` Peter Zijlstra
2024-07-01 10:52   ` Peter Zijlstra
2024-07-11 11:14     ` Adrian Hunter
2024-06-28  6:51 ` [PATCH V8 02/12] perf/x86/intel/pt: Add support for pause / resume Adrian Hunter
2024-07-01 10:46   ` Peter Zijlstra
2024-07-11 13:35     ` Adrian Hunter [this message]
2024-06-28  6:51 ` [PATCH V8 03/12] perf/x86/intel: Do not enable large PEBS for events with aux actions or aux sampling Adrian Hunter
2024-06-28  6:51 ` [PATCH V8 04/12] perf tools: Enable evsel__is_aux_event() to work for ARM/ARM64 Adrian Hunter
2024-06-28  6:51 ` [PATCH V8 05/12] perf tools: Enable evsel__is_aux_event() to work for S390_CPUMSF Adrian Hunter
2024-06-28  6:51 ` [PATCH V8 06/12] perf tools: Add aux_start_paused, aux_pause and aux_resume Adrian Hunter
2024-06-28  6:51 ` [PATCH V8 07/12] perf tools: Add aux-action config term Adrian Hunter
2024-06-28  6:51 ` [PATCH V8 08/12] perf tools: Parse aux-action Adrian Hunter
2024-06-28  6:51 ` [PATCH V8 09/12] perf tools: Add missing_features for aux_start_paused, aux_pause, aux_resume Adrian Hunter
2024-06-28  6:51 ` [PATCH V8 10/12] perf intel-pt: Improve man page format Adrian Hunter
2024-06-28  6:51 ` [PATCH V8 11/12] perf intel-pt: Add documentation for pause / resume Adrian Hunter
2024-06-28  6:51 ` [PATCH V8 12/12] perf intel-pt: Add a test " Adrian Hunter

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=0c59b36f-9b83-475f-b3b2-7fe3649412f4@intel.com \
    --to=adrian.hunter@intel.com \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=brueckner@linux.ibm.com \
    --cc=coresight@lists.linaro.org \
    --cc=hca@linux.ibm.com \
    --cc=irogers@google.com \
    --cc=james.clark@arm.com \
    --cc=jolsa@kernel.org \
    --cc=jonathan.cameron@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mike.leach@linaro.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=suzuki.poulose@arm.com \
    --cc=tmricht@linux.ibm.com \
    --cc=will@kernel.org \
    --cc=yangyicong@hisilicon.com \
    /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).