linux-kernel - Re: [PATCH] perf/core: introduce context per CPU event list

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]

Message-ID: <20161110170132.GI4418@leverpostej>
Date:   Thu, 10 Nov 2016 17:01:33 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     kan.liang@...el.com, mingo@...hat.com,
        linux-kernel@...r.kernel.org, acme@...nel.org, tglx@...utronix.de,
        alexander.shishkin@...ux.intel.com, vince@...ter.net,
        eranian@...gle.com, andi@...stfloor.org
Subject: Re: [PATCH] perf/core: introduce context per CPU event list

On Thu, Nov 10, 2016 at 05:26:32PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 10, 2016 at 02:10:37PM +0000, Mark Rutland wrote:
> 
> > Sure, that sounds fine for scheduling (including big.LITTLE).
> > 
> > I might still be misunderstanding something, but I don't think that
> > helps Kan's case: since INACTIVE events which will fail their filters
> > (including the CPU check) will still be in the tree, they will still
> > have to be iterated over.
> > 
> > That is, unless we also sort the tree by event->cpu, or if in those
> > cases we only care about ACTIVE events and can use an active list.
> 
> A few emails back up I wrote:
> 
> >> If we stick all events in an RB-tree sorted on: {pmu,cpu,runtime} we

Ah, sorry. Clearly I wouldn't pass a reading comprehension test today.

> Looking at the code there's also cgroup muck, not entirely sure where in
> the sort order that should go if at all.
> 
> But having pmu and cpu in there would cure the big-little and
> per-task-per-cpu event issues.

Yup, that all makes sense to me now (modulo the cgroup stuff I also
haven't considered yet).

Thanks,
Mark.