linux-kernel - Re: [RFC] perf: ref-cycle useless with watchdog changes

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: <20160712120238.GM30154@twins.programming.kicks-ass.net>
Date:	Tue, 12 Jul 2016 14:02:38 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Stephane Eranian <eranian@...gle.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	Vince Weaver <vincent.weaver@...ne.edu>,
	Ingo Molnar <mingo@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC] perf: ref-cycle useless with watchdog changes

On Tue, Jul 12, 2016 at 01:24:27AM -0700, Stephane Eranian wrote:
> Hi,
> 
> On Mon, Jul 11, 2016 at 3:33 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> > On Sun, Jul 10, 2016 at 11:48:11AM -0700, Stephane Eranian wrote:
> >> So we either redirect ref-cycles towards 0x013c
> >> (cpu_clk_unhalted:xlck) or another event maybe
> >
> > Another solution is us introducing (another) fake event, say 0x0400,
> > which will have a constrained mask of: 0x0F | (6 << 32) and varies in
> > actual encoding depending on which counter it lands on.
> >
> But if you do this, you cannot give a good definition for that new event.
> It may count core cycles or ref-cycles depending on event scheduling.
> How can you make sense of the result?

As you say below, never expose this to userspace.

> > That way we have more flexibility in scheduling the NMI watchdog, and
> > its exact period isn't _that_ important; although we could obviously
> > also fix up some of that if we wanted.
> >
> Or you're saying 0x0400 is an "internal" event, never exposed to users that is
> used only by the NMI watchdog.

Yes.

> Note that the watchdog is timing-sensitive.

Up to a point, there's a lot of leeway.

> I tend to agree with you that if you use core or ref cycles it will
> work as well given it needs to be setup t seconds granularity. But
> then each event scheduling you'd have to readjust the sampling period
> to be uniform despite the events it is backed with may be different.

Right, we'd have to adjust the period every time we switch to a
different actual event. But its not too horrible if they drift between
CPUs due to such scheduling artifacts. So we can be a bit slow/fast
etc., as long as we're mostly around the right period.

> Wouldn't you need yet another callback for this?  Also given that the
> watchdog is always system-wide pinned and how the scheduling works it
> would tend to give the watchdog the fixed counter for core cycles
> first.

Don't think so, event scheduling is done for every additional counter,
if you add an event with a tighter constraint that might well win from
this special event, since it will have a hweight of 6.

x86_schedule_events() -> perf_assign_events() -> perf_sched_next_event()
iterates through the events starting with the most constrained (wmin)
event and tries adding the more constrained events on top.

So a hweight of 6 will almost guarantee we'll try and fit this event
last, getting whatever option remains open at that time.

But yes, we might need a new callback for this to adjust the actual
encoding and period. I've not really thought through the entire ordeal
too well, it was just a hare brained idea that I threw out there as a
possible solution to look into.