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:   Mon, 11 Dec 2017 07:47:44 -0800
From:   Tejun Heo <tj@...nel.org>
To:     Peter Zijlstra <peterz@...radead.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

Hello, Peter.

On Wed, Dec 06, 2017 at 01:35:00PM +0100, Peter Zijlstra wrote:
> 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.

Understood, but I wonder whether something like this can be made
significantly cheaper and, hopefully, bound.  I could easily be
getting the details wrong, but it doesn't seem like we'd need to
compute much of these dynamically on context switch.

Let's say that we can pre-compute most of mergeable detections and the
value propagation can be pushed to the read time rather than event
time and thus that we can have the same functionality with
insiginficant hot path overhead.  Does that sound like something
acceptable to you?

Thanks.

-- 
tejun