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

[Peter Zijlstra <peterz@infradead.org>]

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@infradead.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.