linux-kernel - Re: [RFC 0/6] optimize ctx switch with rb-tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 26 Apr 2017 12:40:05 -0700
From:   David Carrillo-Cisneros <davidcc@...gle.com>
To:     "Budankov, Alexey" <alexey.budankov@...el.com>
Cc:     "Liang, Kan" <kan.liang@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>, Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andi Kleen <ak@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Borislav Petkov <bp@...e.de>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Vikas Shivappa <vikas.shivappa@...ux.intel.com>,
        Mark Rutland <mark.rutland@....com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Vince Weaver <vince@...ter.net>, Paul Turner <pjt@...gle.com>,
        Stephane Eranian <eranian@...gle.com>,
        "Prohorov, Dmitry" <Dmitry.Prohorov@...el.com>,
        "Cherepennikov, Valery" <Valery.Cherepennikov@...el.com>
Subject: Re: [RFC 0/6] optimize ctx switch with rb-tree

On Wed, Apr 26, 2017 at 3:34 AM, Budankov, Alexey
<alexey.budankov@...el.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