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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALcN6mir0jMw+=AQQhXmvFi+sJPGtbUkAFWhRUkjrOg7GgO7_w@mail.gmail.com>
Date:   Tue, 25 Apr 2017 11:54:36 -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>
Subject: Re: [RFC 0/6] optimize ctx switch with rb-tree

>
> 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