Re: [PATCH v7 5/5] perf metric: Don't compute unused events.

From: Jiri Olsa <jolsa@redhat.com>
To: Ian Rogers <irogers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Namhyung Kim <namhyung@kernel.org>,
	linux-kernel@vger.kernel.org, Andi Kleen <ak@linux.intel.com>,
	Jin Yao <yao.jin@linux.intel.com>,
	John Garry <john.garry@huawei.com>, Paul Clarke <pc@us.ibm.com>,
	kajoljain <kjain@linux.ibm.com>,
	Stephane Eranian <eranian@google.com>,
	Sandeep Dasgupta <sdasgup@google.com>
Subject: Re: [PATCH v7 5/5] perf metric: Don't compute unused events.
Date: Fri, 15 Jan 2021 11:08:29 +0100	[thread overview]
Message-ID: <20210115100829.GA1478666@krava> (raw)
In-Reply-To: <20210112230434.2631593-6-irogers@google.com>

On Tue, Jan 12, 2021 at 03:04:34PM -0800, Ian Rogers wrote:
> For a metric like:
>   EVENT1 if #smt_on else EVENT2
> 
> currently EVENT1 and EVENT2 will be measured and then when the metric is
> reported EVENT1 or EVENT2 will be printed depending on the value from
> smt_on() during the expr parsing. Computing both events is unnecessary and
> can lead to multiplexing as discussed in this thread:
> https://lore.kernel.org/lkml/20201110100346.2527031-1-irogers@google.com/
> 
> This change modifies the expression parsing code by:
>  - getting rid of the "other" parsing and introducing a boolean argument
>    to say whether ids should be computed or not.
>  - expressions are changed so that a pair of value and ids are returned.
>  - when computing the metric value the ids are unused.
>  - when computing the ids, constant values and smt_on are assigned to
>    the value.
>  - If the value is from an event ID then the event is added to the ids
>    hashmap and the value set to bottom (encoded as NAN).
>  - Typically operators union IDs for their inputs and set the value to
>    bottom, however, if the inputs are constant then these are computed and
>    propagated as the value.
>  - If the input is constant to certain operators like:
>  IDS1 if CONST else IDS2
>    then the result will be either IDS1 or IDS2 depending on CONST (which
>    may be evaluated from an entire expression), and so IDS1 or IDS2 may
>    be discarded avoiding events from being programmed.
>  - The ids at the end of parsing are added to the context.

there's lot of refactoring going on, any chance this could be broken
down to more patches?

thanks,
jirka