From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751691AbcGLMCs (ORCPT ); Tue, 12 Jul 2016 08:02:48 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:41213 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751109AbcGLMCq (ORCPT ); Tue, 12 Jul 2016 08:02:46 -0400 Date: Tue, 12 Jul 2016 14:02:38 +0200 From: Peter Zijlstra To: Stephane Eranian Cc: LKML , "ak@linux.intel.com" , Alexander Shishkin , Vince Weaver , Ingo Molnar , Arnaldo Carvalho de Melo , Thomas Gleixner Subject: Re: [RFC] perf: ref-cycle useless with watchdog changes Message-ID: <20160712120238.GM30154@twins.programming.kicks-ass.net> References: <20160711103328.GI30154@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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 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.