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

Message-ID: <CABPqkBRYEFwuQwO2Gef-CHv=MAeQYm=0-RSaJPNG3O5fG4Gp+A@mail.gmail.com>
Date:	Tue, 12 Jul 2016 01:24:27 -0700
From:	Stephane Eranian <eranian@...gle.com>
To:	Peter Zijlstra <peterz@...radead.org>
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

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?

> 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. Note that the watchdog is timing-sensitive.
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. 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.