Messages in this thread | | | Date | Tue, 12 Jul 2016 14:02:38 +0200 | From | Peter Zijlstra <> | 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@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.
| |