Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp9231354ybl; Fri, 17 Jan 2020 08:25:17 -0800 (PST) X-Google-Smtp-Source: APXvYqz1EJvz3gdmvIGbKtPjWj7DAjfmmhPk4q5YWepDqQR1dmzF6ceJPinuTwV+jI4AZR3/80b3 X-Received: by 2002:aca:ec50:: with SMTP id k77mr4097910oih.114.1579278317381; Fri, 17 Jan 2020 08:25:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579278317; cv=none; d=google.com; s=arc-20160816; b=E4VZQmi28cTk8aPRyv65Mp2GVMMNqsbmHtQTGDyzbsyJ9uyWBWXbQOOGCtHRCsaQcT G9xD5ZWFvY4I7XT358DLZZsYftKkgZw6yw/AuWGzyxyc/IIJDjDLcNlPp/cxybiEmSor Rx5j9Ju3uRf4uKwjaXJZaJFMQYavm9RUujfkhgMjF7O1oUZWiHZ61krlsg5YlIhvkbMY ytfUlO3mJp54VOT5LJRxwwbFuEpWy3CRwvvFGnhq3/fqKHF+6WPUVMArPH8KtA5fQIa1 NLrRP/f/lp6JPm/JR269RYATdbHO0PNaAdgfr0OgYsR6e8fRE1lBkcyeL6KowMOCEZQn tr+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=2Rp1Fmo3tN6UejYyYR87NYCK0RlUJeWPFvKDlFbl/tk=; b=aBJpPR39moXmnZPWu77n/gVw02gBM4P0HQVPTsOfLxpprWdFuH0bgm/iweOO0L4mc9 M8d3Gtfsov30UMXMVPB64KfGLvJmjlnrdPaL/L4ysTCp6ZW8USOYDh62OgQB5q3j5OHI Ik8Y04EMdVziGY4RN/MTo8mpPw/VA8IzdIfF+T6XeCoSiZrt2CkNZFGWQjBfcMiLIkHW Jr8HgCFy80nudVF9SxJbhi+19Nwj17lIP4QE1oKw9QHbZ+Dwze/isX4Xaor10LRcmurU m0lMfoh3LtlYv/8QaL96cOKFUP948yWkvsILrvQY1tduC0QjDt3Nd/2PKxv5hgyQywzU 7jXQ== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y65si14305565oia.162.2020.01.17.08.25.04; Fri, 17 Jan 2020 08:25:17 -0800 (PST) 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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729247AbgAQQWh (ORCPT + 99 others); Fri, 17 Jan 2020 11:22:37 -0500 Received: from mga11.intel.com ([192.55.52.93]:41594 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729008AbgAQQWh (ORCPT ); Fri, 17 Jan 2020 11:22:37 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2020 08:22:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,330,1574150400"; d="scan'208";a="243712562" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.21]) by orsmga002.jf.intel.com with ESMTP; 17 Jan 2020 08:22:36 -0800 Received: by tassilo.localdomain (Postfix, from userid 1000) id ABADF300DE4; Fri, 17 Jan 2020 08:22:36 -0800 (PST) Date: Fri, 17 Jan 2020 08:22:36 -0800 From: Andi Kleen To: Peter Zijlstra Cc: kan.liang@linux.intel.com, mingo@redhat.com, acme@kernel.org, linux-kernel@vger.kernel.org, eranian@google.com Subject: Re: [RESEND PATCH V3] perf/x86: Consider pinned events for group validation Message-ID: <20200117162236.GJ302770@tassilo.jf.intel.com> References: <1579201225-178031-1-git-send-email-kan.liang@linux.intel.com> <20200117091341.GX2827@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200117091341.GX2827@hirez.programming.kicks-ass.net> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > So I still completely hate this, because it makes the counter scheduling > more eratic. > > It changes a situation where we only have false-positives (we allow > scheduling a group that might not ever get to run) into a situation > where we can have both false-positives and false-negatives. > > Imagine the pinned event is for a currently running task; and that task > only runs sporadically. Then you can sometimes not create the group, but > mostly it'll work. Right now we have real situations which always fail because of this. > > Yes, this is all very annoying, but I really don't see how this makes > anything any better. The problem this is trying to solve is that some -M metrics fail systematically with the NMI watchdog on. Metrics use weak groups to avoid needing to have the full knowledge how events can be scheduled in the user tools. So they ely on weak groups working. Some of the JSON metrics have groups which always validate, but never schedule with the NMI watchdog on. If you have a better proposal to solve this problem please share it. I suppose we could use export at least the number of available counters in sysfs and then split the groups in the user tools (and assume that's good enough and full counter constraints are not needed) I have some older patches to export the number at least. But fixing the group validation seems better. -Andi