linux-kernel - Re: [RFC] Sharing PMU counters across compatible events

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]

Date:   Wed, 6 Dec 2017 13:35:00 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Tejun Heo <tj@...nel.org>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        linux-kernel@...r.kernel.org, kernel-team@...com,
        alexey.budankov@...ux.intel.com
Subject: Re: [RFC] Sharing PMU counters across compatible events

On Fri, Dec 01, 2017 at 06:19:50AM -0800, Tejun Heo wrote:

> What do you think?  Would this be something worth pursuing?

My worry with the whole thing is that it makes PMU scheduling _far_ more
expensive.

Currently HW PMU scheduling is 'bounded' by the fact that we have
bounded hardware resources (actually placing the events on these
resources is already very complex because not every event can go on
every counter).

We also stop trying to schedule HW events when we find we cannot place
more.

If we were to support this sharing thing (and you were correct in noting
that the specific conditions for matching events is going to be very
tricky indeed), both the above go out the window.

And this is already an area people are optimizing; see for example the
patches here:

  git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/core

(which are WIP, but I got distracted with that whole KAISER stuff) they
make PMU scheduling up to 4x faster for some workload for not having to
iterate through the list finding events for the 'wrong' CPU.

With sharing we can no longer say the hardware is full, we done. But we
have to exhaustively try each and every event, just in case it can
share.

I realize we already have an unbounded case with software events; and we
really should do something about that, instead of making it worse :/