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

[Stephane Eranian]

Hi,

On Mon, Jul 11, 2016 at 3:33 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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.