All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, vince@deater.net,
	eranian@google.com, Arnaldo Carvalho de Melo <acme@infradead.org>,
	Borislav Petkov <bp@suse.de>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 2/2] perf/x86/intel/pt: Allow disabling branch tracing
Date: Wed, 1 Feb 2017 11:17:04 +0100	[thread overview]
Message-ID: <20170201101704.GA450@gmail.com> (raw)
In-Reply-To: <20170127151644.8585-3-alexander.shishkin@linux.intel.com>


* Alexander Shishkin <alexander.shishkin@linux.intel.com> wrote:

> Now that Intel PT supports more types of trace content than just branch
> tracing, it may be useful to allow the user to disable branch tracing
> when it is not needed.
> 
> The special case is BDW, where not setting BranchEn is not supported.
> 
> This patch adds 'no_branch' event format string to PT events, which
> will disable setting BranchEn bit in the hardware trace configuration.

> +	/* trying to unset BRANCH_EN where it is not supported */

Please capitalize comments consistently and use the typical tense. This one should 
be something like:

	/* Try to unset BRANCH_EN where it is not supported: */

>  
>  	reg = pt_config_filters(event);
> -	reg |= RTIT_CTL_TOPA | RTIT_CTL_BRANCH_EN | RTIT_CTL_TRACEEN;
> +	reg |= RTIT_CTL_TOPA | RTIT_CTL_TRACEEN;
> +
> +	/*
> +	 * Previously, we had BRANCH_EN on by default, but now that PT has
> +	 * grown features outside of branch tracing, it is useful to allow
> +	 * the user to disable it. So, to keep compatibility, setting
> +	 * BRANCH_EN bit in the event config (no_branch=1) will have the
> +	 * reverse effect and *not* set BRANCH_EN in the hardware
> +	 * configuration.
> +	 */
> +	if (!(event->attr.config & RTIT_CTL_BRANCH_EN))
> +		reg |= RTIT_CTL_BRANCH_EN;
> +	else
> +		event->attr.config &= ~RTIT_CTL_BRANCH_EN;


So I really hate this ABI hack - it's these unclean approaches how ABIs degrade 
over time, by death of a thousand cuts...

Any reason why we couldn't add a separate pt_feature_branch_disable and 
pt_feature_trace_disable bits and interpret them in a straightforward way, or 
something like that?

( This means two more bits, but that's our punishment for not anticipating 
  extensions to the hardware feature. )

Also, rename "RTIT_CTL_BRANCH_EN" to "RTIT_CTL_PT_EN" (but without changing the 
ABI), to more clearly express what that bit realy does.

I.e. we'd have a hierarchy of flags:

	- the old RTIT_CTL_BRANCH_EN bit (now RTIT_CTL_PT_EN) enables all of PT, 
	  with all features

	- individual feature disabling bits, which default to 0 (i.e. the feature 
	  is enabled) in the attr structure control the finegrained 
	  enabling/disabling of PT features. Currently there are two bits: 
	  pt_feature_branch_disable and pt_feature_branch_enable. More are added 
	  in the future if PT grows even more features.

or so?

Thanks,

	Ingo

  reply	other threads:[~2017-02-01 10:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-27 15:16 [PATCH 0/2] perf/x86/intel/pt: Misc updates Alexander Shishkin
2017-01-27 15:16 ` [PATCH 1/2] perf/x86/intel/pt: Add format strings for PTWRITE and power event tracing Alexander Shishkin
2017-02-01 10:21   ` [tip:perf/core] " tip-bot for Alexander Shishkin
2017-01-27 15:16 ` [PATCH 2/2] perf/x86/intel/pt: Allow disabling branch tracing Alexander Shishkin
2017-02-01 10:17   ` Ingo Molnar [this message]
2017-02-01 16:49     ` Alexander Shishkin
2017-02-02 10:14       ` Alexander Shishkin
2017-02-06 14:41         ` [PATCH] " Alexander Shishkin
2017-02-06 15:58           ` Andi Kleen
2017-02-06 16:05             ` Alexander Shishkin
2017-02-06 17:19               ` Andi Kleen
2017-04-27  8:11                 ` Adrian Hunter
2017-03-30  8:33           ` [tip:perf/core] perf/x86/intel/pt: Allow the disabling of " tip-bot for Alexander Shishkin

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=20170201101704.GA450@gmail.com \
    --to=mingo@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@infradead.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=bp@suse.de \
    --cc=eranian@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=vince@deater.net \
    /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.