MIME-Version: 1.0
In-Reply-To: <E3138441316DDA4991F87D33FA402D406780453B@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>
 <CALcN6mir0jMw+=AQQhXmvFi+sJPGtbUkAFWhRUkjrOg7GgO7_w@mail.gmail.com> <E3138441316DDA4991F87D33FA402D406780453B@IRSMSX106.ger.corp.intel.com>
From: David Carrillo-Cisneros <davidcc@google.com>
Date: Wed, 26 Apr 2017 12:40:05 -0700
Message-ID: <CALcN6mhcLuw2i6fegOrXQc6pyW-NJhfphX=N0uEpKX2_+0OHiQ@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>,
        "Prohorov, Dmitry" <Dmitry.Prohorov@intel.com>,
        "Cherepennikov, Valery" <Valery.Cherepennikov@intel.com>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2013
Lines: 44

On Wed, Apr 26, 2017 at 3:34 AM, Budankov, Alexey
<alexey.budankov@intel.com> wrote:
> Hi David,
>
> I would like to take over on the patches development relying on your help with reviews.

Sounds good.

> Could you provide me with the cumulative patch set to expedite the ramp up?

This RFC is my latest version. I did not have a good solution on how
to solve the problem of handling failure of PMUs that share contexts,
and to activate/inactivate them.

Some things to keep in mind when dealing with task-contexts are:
  1. The number of PMUs is large and growing, iterating over all PMUs
may be expensive (see https://lkml.org/lkml/2017/1/18/859 ).
  2. event_filter_match in this RFC is only used because I did not
find a better ways to filter out events with the rb-tree. It would be
nice if we wouldn't have to check event->cpu != -1 && event->cpu ==
smp_processor_id() and cgroup stuff for every event in task contexts.
  3. I used the inactive events list in this RFC as a cheaper
alternative to threading the rb-tree but it has the problem that
events that are removed due to conflict would be placed at the end of
the list even if didn't run. I cannot recall if that ever happens.
Using this list also causes problem (2.) maybe threading the tree is a
better alternative?
  4. Making the key in task-events to be {PMU,CPU,last_time_scheduled}
(as opposed to {CPU,last_time_scheduled} in the RFC) may simplify
sched in by helping to iterate over all events in same PMU at once,
simplifying the activation/inactivation of the PMU and making it
simple to move to the next PMU on pmu::add errors. The problem with
this approach is to find only the PMUs with inactive events without
traversing a list of all PMUs. Maybe a per-context list of active PMUs
may help (see 1.).

cpu-contexts are much simpler and I think work well with what the RFC
does (they are per-pmu already).

This thread has Peter and Mark's original discussion of the rb-tree
(https://patchwork.kernel.org/patch/9176121/).

Thanks,
David