Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5363897yba; Mon, 13 May 2019 09:35:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqyn0mUjblcBuNmFze8sNP7sGN9Bo6IRXpFlmZ0sSBkp+ivYHXa0DT/dzhuwkStcK9hhUiG1 X-Received: by 2002:a17:902:b581:: with SMTP id a1mr31778940pls.206.1557765327175; Mon, 13 May 2019 09:35:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557765327; cv=none; d=google.com; s=arc-20160816; b=uEZfoi60xb5Xrkp5feS9zSc1FLJ7R9BeZvpGUG/XQ/h7f3LTg8GKhNjvvH5b02v3xU sbmQDQB61EUjDlIxpIW0+CPulqpwOTz0DbeEYBtA8ZR5Xei+0FYh1YSknRMzsWcX0xHB 4TypaC9i+UyYUP2MLa30mzQ9FdU7n5cpU1WRJsjb9RV0uzTOjydRBEsPfgk+CsuqH8wn 9vxXWFyh7BgD2g7zZBDVBDbmB6omKv091yWewhVfMBIp8hZimSDEyCxKlLpfaUmCaPUd 7cggicclRUxnk083cp74ebEQefWmd0+6dRTqLHjpFvAoCuPlskHcMxzFDc1Mrl9FJSUi xhKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=2/pZQCYHBRt5vZjBZiV+jXqyYA3iPhVXwNe1J6JTT5Q=; b=LS2H8vWMSg/diKP8m3jtJWjPm+h4Chmb0ZFpVo3Dc+J7Z6KWTzXSnfSgxbEU/ZcPyA 2m+uaskCNQE+ZfSLZi7izPmOI/ptrDzYbQatZFniHTFV7aFuLBiO0wBjui04RCJMltgr SNrnA7xY9q3Qc4A6tvjSDzf6rojiErVeMlotE8J5s4Wz7WroTTxSS018tjaGj+7R9Nkq r5Qv+4Vj1g9JYsHHPbJmD8t8tUgWGruyWNLJP4ks6UCIjqy8/jNAaC2J3PS1UA+BnDUl o2Fl8yFnnE1cs8huo8ZYXG52h3nra5sOiJ4RlKWKyEVmnMMhbM4pLGA+r13NOJ8fbX78 Drww== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=21LRkYCI; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u8si16004711plz.5.2019.05.13.09.35.09; Mon, 13 May 2019 09:35:27 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=21LRkYCI; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731113AbfEMPGd (ORCPT + 99 others); Mon, 13 May 2019 11:06:33 -0400 Received: from merlin.infradead.org ([205.233.59.134]:56122 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728659AbfEMPGc (ORCPT ); Mon, 13 May 2019 11:06:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2/pZQCYHBRt5vZjBZiV+jXqyYA3iPhVXwNe1J6JTT5Q=; b=21LRkYCIu+9y35kAOJwzsIntS j1JVTBcrifsbUMBdiCv0OXnIGwa7vEcK+5xsZrnpLyiQ/qL4Ql1RazGalQTM1GcLRXPCo0K88iEUa Gg9AIxmVcew2xxKafQ/S1GVO4ZNEuoTHphQyUyO5q8Mawm41TDA3/7MB9kyyk1r/0TogczRIoPRbN zmFdPuP10/39OO136NJ2oL/vo9C53k9oaDrbuYKk143w/B1pH9XKLRwsdjy4QKkKQdNY6rJjBHniP QsL5XVscOxodLB0AlVgLH5BRPv0bMm6PXKb8w07anonG8Uguykd8Qg59QtOKq0vdpYRwLcE2LVUQq dwf5TdyWw==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1hQCWz-0007zz-7n; Mon, 13 May 2019 15:06:21 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id EAC962029FD7A; Mon, 13 May 2019 17:06:19 +0200 (CEST) Date: Mon, 13 May 2019 17:06:19 +0200 From: Peter Zijlstra To: Qais Yousef Cc: Ingo Molnar , Steven Rostedt , linux-kernel@vger.kernel.org, Pavankumar Kondeti , Sebastian Andrzej Siewior , Uwe Kleine-Konig , Dietmar Eggemann , Quentin Perret Subject: Re: [PATCH v2 0/7] Add new tracepoints required for EAS testing Message-ID: <20190513150619.GX2589@hirez.programming.kicks-ass.net> References: <20190510113013.1193-1-qais.yousef@arm.com> <20190513122857.GU2623@hirez.programming.kicks-ass.net> <20190513134203.xmw6rsjwpj5b4tj6@e107158-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190513134203.xmw6rsjwpj5b4tj6@e107158-lin.cambridge.arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 13, 2019 at 02:42:03PM +0100, Qais Yousef wrote: > On 05/13/19 14:28, Peter Zijlstra wrote: > > > > > > diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h > > index c8c7c7efb487..11555f95a88e 100644 > > --- a/include/trace/events/sched.h > > +++ b/include/trace/events/sched.h > > @@ -594,6 +594,23 @@ TRACE_EVENT(sched_wake_idle_without_ipi, > > > > TP_printk("cpu=%d", __entry->cpu) > > ); > > + > > +/* > > + * Following tracepoints are not exported in tracefs and provide hooking > > + * mechanisms only for testing and debugging purposes. > > + */ > > +DECLARE_TRACE(pelt_cfs_rq, > > + TP_PROTO(struct cfs_rq *cfs_rq), > > + TP_ARGS(cfs_rq)); > > + > > +DECLARE_TRACE(pelt_se, > > + TP_PROTO(struct sched_entity *se), > > + TP_ARGS(se)); > > + > > +DECLARE_TRACE(sched_overutilized, > > + TP_PROTO(int overutilized), > > + TP_ARGS(overutilized)); > > + > > If I decoded this patch correctly, what you're saying: > > 1. Move struct cfs_rq to the exported sched.h header No, don't expose the structure, we want to keep that private. You can use unqualified pointers. > 2. Get rid of the fatty wrapper functions and export any necessary > helper functions. Right, that should get them read-only access to the members of those structures and avoids the tracing code itself from becoming ugleh and also avoids us having to export those structures (which we really don't want to do). > 3. No need for RT and DL pelt tracking at the moment. Nah, you probably want rt,dl,irq (as Dietmar pointed out), it's just that your patched didn't do it right and I was lazy. > I'm okay with this. The RT and DL might need to be revisited later but we don't > have immediate need for them now. > > I'll add to this passing rd->span to sched_overutilizied. Or pass the rd itself and add another wrapper to extract the span.