Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 12 Oct 2018 11:50:01 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Song Liu <songliubraving@fb.com>
Cc:     Ingo Molnar <mingo@kernel.org>,
        lkml <linux-kernel@vger.kernel.org>,
        "acme@kernel.org" <acme@kernel.org>,
        "alexander.shishkin@linux.intel.com" 
        <alexander.shishkin@linux.intel.com>,
        "jolsa@redhat.com" <jolsa@redhat.com>,
        "eranian@google.com" <eranian@google.com>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "alexey.budankov@linux.intel.com" <alexey.budankov@linux.intel.com>,
        "mark.rutland@arm.com" <mark.rutland@arm.com>,
        "megha.dey@intel.com" <megha.dey@intel.com>,
        "frederic@kernel.org" <frederic@kernel.org>
Subject: Re: [RFC][PATCH] perf: Rewrite core context handling
Message-ID: <20181012095001.GG9867@hirez.programming.kicks-ass.net>
References: <20181010104559.GO5728@hirez.programming.kicks-ass.net>
 <D2014055-9B25-4152-A582-7AD42A3837AB@fb.com>
 <20181011092913.GA9848@hirez.programming.kicks-ass.net>
 <70079805-1CAE-4CAA-813A-F8DDB929F22B@fb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <70079805-1CAE-4CAA-813A-F8DDB929F22B@fb.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


Can we please not top-post?

On Thu, Oct 11, 2018 at 10:37:14PM +0000, Song Liu wrote:
> Thanks Peter! These are really really helpful. 
> 
> I am trying to think through the case of a group of two events on two 
> separate hardware PMUs. In current implementation, this will not trigger
> move_group,

Right, currently this is disallowed (or should be, I'll need to double
check the code).

> so they will not be able to rotate together? And actually, 
> they may not be able to run at all? Maybe this case is never supported? 

Indeed, we do not allow mixing events of different PMUs, with the
explicit exception of software events. Since software events must always
schedule, they're allowed to be fitted into any group.

> On the other hand, would something like this work:
> 
>     perf_cpu_context <-[1:2]-> perf_event_context <-[1:n]-> perf_event 
>               |                                                |
>               `----[1:n]---->     pmu    <----- [1:n]----------' 
> 
> 1. Every cpu has only one perf_cpu_context. No perf_cpu_pmu_context. 

The perf_event_pmu_context is currently needed to efficiently track
which events are active. And to determine if rotation is needed at all.

And the perf_cpu_pmu_context is needed because the rotation is per PMU
in ABI.

> 2. perf_cpu_context has two perf_event_context, one for the cpu, the 
>    other for the task. 

That doesn't work (or I'm not understanding), tasks come and go on CPUs,
at best it has a reference to the current active task's context. But it
already had that, and it still does, see perf_cpu_context::task_ctx.

> 3. Each perf_event_context has 3 perf_event_groups, pinned_groups, 
>    flexible_groups, and software_groups (for sw event only groups). 

So I'm thinking you want to split off the software groups because they
don't need rotation?

While doing this patch I noticed that we need to ignore attr.exclusive
for software events. Not sure that was intentional or not, but certainly
inconsistent.

> 4. All flexible_groups of the same cpu rotate a the same time. If 
>    there are two hardware PMUs on the cpu, the rotation will look 
>    like: 1) stop both PMUs; 2) rotate events; 3) start both PMUs. 

ABI precludes that currently, we have per PMU rotation intervals exposed
in sysfs.

> I feel this will make the implementation simpler. Is it too broken in 
> some cases? Or did I miss anything obvious? One thing I noticed is 
> that we need to drop per PMU config perf_event_mux_interval_ms. 

Right that. People added that for a reason (although it eludes me atm).
I don't think we can drop that easily.