Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp572287ybv; Thu, 20 Feb 2020 03:40:22 -0800 (PST) X-Google-Smtp-Source: APXvYqx17/hWljfkd4/AeeW2LhU82YkffrsgYRw4KoZEenBU2OlXnZg7do3pNcxWW9evprJ4RnH6 X-Received: by 2002:a05:6830:22ee:: with SMTP id t14mr22630503otc.236.1582198822699; Thu, 20 Feb 2020 03:40:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582198822; cv=none; d=google.com; s=arc-20160816; b=XBANV4JKl+1HyUiEqvBPqLpqRHgjUUtqE406Mu0iuI2sTbEaDo/TXKx7HDS0C0883u xBtQEcuCm+TSKeLAAmt9iV5VPojjAaYrjGElKjT2OSRiikO9PJ7EGbFzWdS/JQAwk6lL OZmrZWGmpLxr8v/hYes2RS5G2VRh920tKeN+9DBnMvzOonTkxUfS9cfimmSdjBytp3MV 3LXBpknFwbKkhMpAlPra+Uf3Khn2EMLyOJzHDsPWzPVVqU4fAjrPlaqqTLstEQvYrFHG HLWuG8khiUn2xhGeDw2BEL+7wIrW3M0+r5fWDvh5pZDsG5NBLPFNzYjxsJj356XV1HYx erqA== 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 :dkim-signature; bh=65azVoQTkiBxYIIGWnRhyuI479FEvbLqbTexlaKEWfQ=; b=Za4l88vnuPNmBCUbAWGutddhGuwB+jogbVkUykb1Q6bc0u6a/4prYOyyPHjKyuGBAW A2LkLzpv9gzvt3OwLJyqMG3VSOjgGbCoC3nJf2C0fFzIiCTY6sg24ShJYMZmidbGqs02 4FFR4HZHEMoxzhSyYk0huFjeQ7ai+5BqlAhJ7EY2EK/rLoGTZzgyifPrx9aSuszQTadP afFIiyfEkbxLyDAgYnPEzYi6wAioYwncyZfDv4uho9u6Ewtfj5qW/eOtU6hw4mNtavNb 89Wb0VLSAUDyI0CxysqFX3EFnbvI16I/OesqRw1ZUIik7kbOVy/SGWyNULktbDiVs6uy U20g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=etGhjExw; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 13si10974294oiy.28.2020.02.20.03.40.10; Thu, 20 Feb 2020 03:40:22 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=etGhjExw; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727806AbgBTLjh (ORCPT + 99 others); Thu, 20 Feb 2020 06:39:37 -0500 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:47080 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726885AbgBTLjh (ORCPT ); Thu, 20 Feb 2020 06:39:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582198776; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=65azVoQTkiBxYIIGWnRhyuI479FEvbLqbTexlaKEWfQ=; b=etGhjExwAtCuRqAti2Buu6qyfzM/R5Dk/RoKyatXY5Wt9Ka0w8+Pi5SPahORYdrHOp9Uwd HmLNmijCnLUHiDoWAN+/AK/HF0C9UFr89Dg3mJPjDsvjnXrL1hmY+VFj/RHHJMDOmC7eO0 Z6Q/uTFVm93PSbSZEl6ERM7x3dBj1VE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-115-kLrUMjIuM_CrQFFILUFRAQ-1; Thu, 20 Feb 2020 06:39:30 -0500 X-MC-Unique: kLrUMjIuM_CrQFFILUFRAQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3156718C35A0; Thu, 20 Feb 2020 11:39:29 +0000 (UTC) Received: from krava (unknown [10.43.17.9]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 261B890F79; Thu, 20 Feb 2020 11:39:26 +0000 (UTC) Date: Thu, 20 Feb 2020 12:39:24 +0100 From: Jiri Olsa To: kan.liang@linux.intel.com Cc: acme@kernel.org, mingo@redhat.com, peterz@infradead.org, linux-kernel@vger.kernel.org, mark.rutland@arm.com, namhyung@kernel.org, ravi.bangoria@linux.ibm.com, yao.jin@linux.intel.com, ak@linux.intel.com Subject: Re: [PATCH 0/5] Support metric group constraint Message-ID: <20200220113924.GB565976@krava> References: <1582139320-75181-1-git-send-email-kan.liang@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1582139320-75181-1-git-send-email-kan.liang@linux.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 19, 2020 at 11:08:35AM -0800, kan.liang@linux.intel.com wrote: > From: Kan Liang > > Some metric groups, e.g. Page_Walks_Utilization, will never count when > NMI watchdog is enabled. > > $echo 1 > /proc/sys/kernel/nmi_watchdog > $perf stat -M Page_Walks_Utilization > > Performance counter stats for 'system wide': > > itlb_misses.walk_pending (0.00%) > dtlb_load_misses.walk_pending (0.00%) > dtlb_store_misses.walk_pending (0.00%) > ept.walk_pending (0.00%) > cycles (0.00%) > > 2.343460588 seconds time elapsed > > Some events weren't counted. Try disabling the NMI watchdog: > echo 0 > /proc/sys/kernel/nmi_watchdog > perf stat ... > echo 1 > /proc/sys/kernel/nmi_watchdog > The events in group usually have to be from the same PMU. Try > reorganizing the group. > > A metric group is a weak group, which relies on group validation > code in the kernel to determine whether to be opened as a group or > a non-group. However, group validation code may return false-positives, > especially when NMI watchdog is enabled. (The metric group is allowed > as a group but will never be scheduled.) > > The attempt to fix the group validation code has been rejected. > https://lore.kernel.org/lkml/20200117091341.GX2827@hirez.programming.kicks-ass.net/ > Because we cannot accurately predict whether the group can be scheduled > as a group, only by checking current status. > > This patch set provides another solution to mitigate the issue. > Add "MetricConstraint" in event list, which provides a hint for perf tool, > e.g. "MetricConstraint": "NO_NMI_WATCHDOG". Perf tool can change the > metric group to non-group (standalone metrics) if NMI watchdog is enabled. the problem is in the missing counter, that's taken by NMI watchdog, right? and it's problem for any metric that won't fit to the available counters.. shouldn't we rather do this workaround for any metric that wouldn't fit in available counters? not just for chosen ones..? thanks, jirka