Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp3303009ybg; Sun, 20 Oct 2019 10:54:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqyZQfBCzm4yItwCTdoQn6ISYqSHlXyNkUQ7lg7fwUE9ZzGEFheqDhB7W7U1WAaTASGfTEl1 X-Received: by 2002:a05:6402:557:: with SMTP id i23mr20579132edx.71.1571594061111; Sun, 20 Oct 2019 10:54:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571594061; cv=none; d=google.com; s=arc-20160816; b=G9cLtqtu6sLEitndP7NAfz2Adde/q/VFlKKFXehDTYGu8wRraXIwLQsPlYXdixGUd4 LgCqjhzdpk7tpZJ9Qu2DyDCUBlB8ekU6CzsnymX02Xdcws1wRD0/d0rEfucpo2e6kcZX Ins6OACIV5s04AvsjJwRuflHgzGFaYHy378zgcICOpCXFxbgtmA8Z7CGGmzBmRWaOrPw XhS7LU7dahsw6qgOew/tzgt42z3B+0re4swkkYDbfTMibGXqf+syO+AFyvOK3aOvf1hc 80oV2isiJu80AFHVozVMF4+pS6vij0/Udweiq+Hdz/EB2Uzdsr9Xb6wQ+jf1c4ZOK4fJ z9sA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=toawPPOFRLsmz11/e5dJqREPBisnM7KMV6dyS3k60S0=; b=SuqTemuG+OIK9Uf2+/oQhZZ9tHt/iSG9JJIc6uBO9zTHMp9ECeyziGhn6PQn2ZC5XJ wnQfScn5/W1GFbY/KSpzC7etDbXjdu0jZHrzGFi/b7wQqhwF8d0+xQNkfTP7m8EDEj7k 03bggshuR6VY3iA0K3evu/b/xUaaWFr59YExdQMX/RxPm8SUVIi0YI/72694RW+Bjv5c vqwSi0Xpq2X1CznU4C+iuPsaonr33wmudcJYk4GNrxAKxTddVzZi+rCKZo5evPS/VnqA iqJ0KbiL7FgxQy1NFhYDnfeSXveYxoXtRk6TPECqpWq6UmmEl5qqf+bjyDto9RWgapiO m+bg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l3si8092643edc.109.2019.10.20.10.53.57; Sun, 20 Oct 2019 10:54:21 -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; 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 S1726822AbfJTRwc (ORCPT + 99 others); Sun, 20 Oct 2019 13:52:32 -0400 Received: from mga07.intel.com ([134.134.136.100]:35220 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726711AbfJTRwb (ORCPT ); Sun, 20 Oct 2019 13:52:31 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Oct 2019 10:52:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,320,1566889200"; d="scan'208";a="196640328" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.137]) by fmsmga007.fm.intel.com with ESMTP; 20 Oct 2019 10:52:30 -0700 Received: by tassilo.localdomain (Postfix, from userid 1000) id 019C73002BE; Sun, 20 Oct 2019 10:52:29 -0700 (PDT) From: Andi Kleen To: acme@kernel.org Cc: linux-kernel@vger.kernel.org, jolsa@kernel.org, eranian@google.com, kan.liang@linux.intel.com, peterz@infradead.org Subject: Optimize perf stat for large number of events/cpus v2 Date: Sun, 20 Oct 2019 10:51:53 -0700 Message-Id: <20191020175202.32456-1-andi@firstfloor.org> X-Mailer: git-send-email 2.21.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [The earlier v1 version had a lot of conflicts against some recent libperf changes in tip/perf/core. Resolve that and also fix some minor issues.] This patch kit optimizes perf stat for a large number of events on systems with many CPUs and PMUs. Some profiling shows that the most overhead is doing IPIs to all the target CPUs. We can optimize this by using sched_setaffinity to set the affinity to a target CPU once and then doing the perf operation for all events on that CPU. This requires some restructuring, but cuts the set up time quite a bit. In theory we could go further by parallelizing these setups too, but that would be much more complicated and for now just batching it per CPU seems to be sufficient. At some point with many more cores parallelization or a better bulk perf setup API might be needed though. In addition perf does a lot of redundant /sys accesses with many PMUs, which can be also expensve. This is also optimized. On a large test case (>700 events with many weak groups) on a 94 CPU system I go from real 0m8.607s user 0m0.550s sys 0m8.041s to real 0m3.269s user 0m0.760s sys 0m1.694s so shaving ~6 seconds of system time, at slightly more cost in perf stat itself. On a 4 socket system with the savings are more dramatic: real 0m15.641s user 0m0.873s sys 0m14.729s to real 0m4.493s user 0m1.578s sys 0m2.444s so 11s difference in the user visible set up time. Also available in git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc perf/stat-scale-4 v1: Initial post. v2: Rebase. Fix some minor issues. -Andi