Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 25 Aug 2022 11:17:29 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Ravi Bangoria <ravi.bangoria@amd.com>
Cc:     acme@kernel.org, alexander.shishkin@linux.intel.com,
        jolsa@redhat.com, namhyung@kernel.org, songliubraving@fb.com,
        eranian@google.com, alexey.budankov@linux.intel.com,
        ak@linux.intel.com, mark.rutland@arm.com, megha.dey@intel.com,
        frederic@kernel.org, maddy@linux.ibm.com, irogers@google.com,
        kim.phillips@amd.com, linux-kernel@vger.kernel.org,
        santosh.shukla@amd.com
Subject: Re: [RFC v2] perf: Rewrite core context handling
Message-ID: <Ywc+Kc7p9svJ79ml@worktop.programming.kicks-ass.net>
References: <20220113134743.1292-1-ravi.bangoria@amd.com>
 <YqdLH+ZU/sf4n0pa@hirez.programming.kicks-ass.net>
 <YwYWUbVvSAYseDaO@worktop.programming.kicks-ass.net>
 <YwY8u7gx6bO+RBcg@worktop.programming.kicks-ass.net>
 <10d8889e-4ca9-7e4e-a3e4-d769da79d047@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <10d8889e-4ca9-7e4e-a3e4-d769da79d047@amd.com>
Precedence: bulk

On Thu, Aug 25, 2022 at 11:09:05AM +0530, Ravi Bangoria wrote:
> > -static inline int __pmu_filter_match(struct perf_event *event)
> > -{
> > -	struct pmu *pmu = event->pmu;
> > -	return pmu->filter_match ? pmu->filter_match(event) : 1;
> > -}
> > -
> > -/*
> > - * Check whether we should attempt to schedule an event group based on
> > - * PMU-specific filtering. An event group can consist of HW and SW events,
> > - * potentially with a SW leader, so we must check all the filters, to
> > - * determine whether a group is schedulable:
> > - */
> > -static inline int pmu_filter_match(struct perf_event *event)
> > -{
> > -	struct perf_event *sibling;
> > -
> > -	if (!__pmu_filter_match(event))
> > -		return 0;
> > -
> > -	for_each_sibling_event(sibling, event) {
> > -		if (!__pmu_filter_match(sibling))
> > -			return 0;
> > -	}
> > -
> > -	return 1;
> > -}
> > -
> >  static inline int
> >  event_filter_match(struct perf_event *event)
> >  {
> >  	return (event->cpu == -1 || event->cpu == smp_processor_id()) &&
> > -	       perf_cgroup_match(event) && pmu_filter_match(event);
> > +	       perf_cgroup_match(event);
> 
> There are many callers of event_filter_match() which might not endup calling
> visit_groups_merge(). I hope this is intentional change?

I thought I did, but lets go through them again.

event_filter_match() is called from:

 - __perf_event_enable(); here we'll end up in ctx_sched_in() which
   will dutifully skip the pmu in question.

   (fwiw, this is one of those sites where ctx_sched_{out,in}() could do
   with a @pmu argument.

 - merge_sched_in(); this is after the new callsite in
   visit_groups_merge().

 - perf_adjust_freq_unthrottle_context(); if the pmu was skipped in
   visit_groups_merge() then ->state != ACTIVE and we'll bail out.

 - perf_iterate_ctx() / perf_iterate_sb_cpu(); these are for generating
   side-band events, and arguably not delivering them when running on
   the 'wrong' CPU wasn't right to begin with.


So I tihnk we're good. Hmm?