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:   Mon, 15 Oct 2018 10:34:48 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Alexey Budankov <alexey.budankov@linux.intel.com>
Cc:     mingo@kernel.org, linux-kernel@vger.kernel.org, acme@kernel.org,
        alexander.shishkin@linux.intel.com, jolsa@redhat.com,
        songliubraving@fb.com, eranian@google.com, tglx@linutronix.de,
        mark.rutland@arm.com, megha.dey@intel.com, frederic@kernel.org
Subject: Re: [RFC][PATCH] perf: Rewrite core context handling
Message-ID: <20181015083448.GN9867@hirez.programming.kicks-ass.net>
References: <20181010104559.GO5728@hirez.programming.kicks-ass.net>
 <3a738a08-2295-a4e9-dce7-a3e2b2ad794e@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3a738a08-2295-a4e9-dce7-a3e2b2ad794e@linux.intel.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Oct 15, 2018 at 10:26:06AM +0300, Alexey Budankov wrote:
> Hi,
> 
> On 10.10.2018 13:45, Peter Zijlstra wrote:
> > Hi all,
> > 
> > There have been various issues and limitations with the way perf uses
> > (task) contexts to track events. Most notable is the single hardware PMU
> > task context, which has resulted in a number of yucky things (both
> > proposed and merged).
> > 
> > Notably:
> > 
> >  - HW breakpoint PMU
> >  - ARM big.little PMU
> >  - Intel Branch Monitoring PMU
> > 
> > Since we now track the events in RB trees, we can 'simply' add a pmu
> > order to them and have them grouped that way, reducing to a single
> > context. Of course, reality never quite works out that simple, and below
> > ends up adding an intermediate data structure to bridge the context ->
> > pmu mapping.
> > 
> > Something a little like:
> > 
> >               ,------------------------[1:n]---------------------.
> >               V                                                  V
> >     perf_event_context <-[1:n]-> perf_event_pmu_context <--- perf_event
> >               ^                      ^     |                     |
> >               `--------[1:n]---------'     `-[n:1]-> pmu <-[1:n]-'
> > 
> > This patch builds (provided you disable CGROUP_PERF), boots and survives
> > perf-top without the machine catching fire.
> > 
> > There's still a fair bit of loose ends (look for XXX), but I think this
> > is the direction we should be going.
> > 
> > Comments?
> > 
> > Not-Quite-Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > ---
> >  arch/powerpc/perf/core-book3s.c |    4 
> >  arch/x86/events/core.c          |    4 
> >  arch/x86/events/intel/core.c    |    6 
> >  arch/x86/events/intel/ds.c      |    6 
> >  arch/x86/events/intel/lbr.c     |   16 
> >  arch/x86/events/perf_event.h    |    6 
> >  include/linux/perf_event.h      |   80 +-
> >  include/linux/sched.h           |    2 
> >  kernel/events/core.c            | 1412 ++++++++++++++++++++--------------------
> >  9 files changed, 815 insertions(+), 721 deletions(-)
> 
> Rewrite is impressive however it doesn't result in code base reduction as it is.

Yeah.. that seems to be nature of these things ..

> Nonetheless there is a clear demand for per pmu events groups tracking and rotation 
> in single cpu context (HW breakpoints, ARM big.little, Intel LBRs) and there is 
> a supply thru groups ordering on RB-tree.
> 
> This might be driven into the kernel by some new Perf features that would base on 
> that RB-tree groups ordering or by refactoring of existing code but in the way it 
> would result in overall code base reduction thus lowering support cost.

If you have a concrete suggestion on how to reduce complexity? I tried,
but couldn't find any (without breaking something).

The active lists and pmu_ctx_list could arguably be replaced with
(slower) iteratons over the RB tree, but you'll still need the per pmu
nr_events/nr_active counts to determine if rotation is required at all.

And like you know, performance is quite important here too. I'd love to
reduce complexity while maintaining or improve performance, but that
rarely if ever happens :/