MIME-Version: 1.0
In-Reply-To: <E3138441316DDA4991F87D33FA402D40678033B3@IRSMSX106.ger.corp.intel.com>
References: <20170110102502.106187-1-davidcc@google.com> <37D7C6CF3E00A74B8858931C1DB2F077536E6010@SHSMSX103.ccr.corp.intel.com>
 <CALcN6miYEYaxnSshy78mduOureT1kYNo6OLunwbjVPZvSnCogg@mail.gmail.com> <E3138441316DDA4991F87D33FA402D40678033B3@IRSMSX106.ger.corp.intel.com>
From: David Carrillo-Cisneros <davidcc@google.com>
Date: Tue, 25 Apr 2017 11:54:36 -0700
Message-ID: <CALcN6mir0jMw+=AQQhXmvFi+sJPGtbUkAFWhRUkjrOg7GgO7_w@mail.gmail.com>
Subject: Re: [RFC 0/6] optimize ctx switch with rb-tree
To: "Budankov, Alexey" <alexey.budankov@intel.com>
Cc: "Liang, Kan" <kan.liang@intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "x86@kernel.org" <x86@kernel.org>, Ingo Molnar <mingo@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>, Andi Kleen <ak@linux.intel.com>,
        Peter Zijlstra <peterz@infradead.org>, Borislav Petkov <bp@suse.de>,
        Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Vikas Shivappa <vikas.shivappa@linux.intel.com>,
        Mark Rutland <mark.rutland@arm.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Vince Weaver <vince@deater.net>, Paul Turner <pjt@google.com>,
        Stephane Eranian <eranian@google.com>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1321
Lines: 28

>
> If I disable traversing in the per-process case then the overhead disappears.
>
> For the system-wide case the ctx->pinned_groups and ctx->flexible_groups lists are parts of per-cpu perf_cpu_context object and count of iterations is small (#events == 29).


Yes, seems like it would benefit from the rb-tree optimization.

Something that is wrong in my RFC (as Mark notes in the "enjoyment"
section of  https://lkml.org/lkml/2017/1/12/254), is that care must be
taken to disable the right pmu when dealing with contexts that have
events from more than one PMU. A way to do it is to have the pmu as
part of the rb-tree key (as Peter initially suggested) and use that to
iterate events in the same pmu together.

There's still the open question of what to do when pmu->add fails.
Currently, it stops scheduling events, but that's not right when
dealing with events in "software context" that are not software events
(I am looking at you CQM) and in hardware contexts with more than one
PMU (ARM big-little). Ideally a change in event scheduler should
address that, but it requires more work. Here is a discussion with
Peter about that (https://lkml.org/lkml/2017/1/25/365).

If you guys want to work on it, I'll be happy to help review.
Otherwise, I'll get to it as soon as I have a chance (1-2 months).

Thanks,
David