Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp7294052ybp; Wed, 16 Oct 2019 06:45:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqw15zEIUy2OhbHK+dQCGoc5t+LBS83wLj3GXGcjKnNPSkfwujSJW84OUbz96nzWB5v25DSQ X-Received: by 2002:a17:906:d8c3:: with SMTP id re3mr39948902ejb.167.1571233509306; Wed, 16 Oct 2019 06:45:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571233509; cv=none; d=google.com; s=arc-20160816; b=cfceiqZbKeQQ3prk8S32/y5zkzD1nJPTomYDlPpPr3AgkC4BXnCGeF163oSHlLnih+ fhkEx8sqy+O4jt0+BvujlurWyyHMPVPp8UZ9c8QAcz4gHhdkQDC8V5JBMyN6MeaWsMq4 3Lx/CMiqtYvHAKyUistdR+1lcUS+hijBD+1nToJhb+fEudPxyEsPMdxlOPMVpO7Yhftk BOZDlojg0BT22JB0C/Jxm/OFN4WM7IOYDEy8JRPocYcDAS1oPPJQc7n2t3msN1jNkD3q ti8RjEolrPHRyPlKHeXgaBH0qrytP7IaHIsocW2rL1nVjaiGFFOQpsQdsdvPMYXtZmAc gtZw== 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 :content-language:mime-version:user-agent:date:message-id:cc:to :organization:subject:from; bh=Mfi0V3r26CbzbZDpxChZ7uscR9xMsOZTd5nJHIqIzsQ=; b=0A8Nm7Q6PeAipHYWRvEPHHQ73KDlWhDYNQfej4ynt0WwzPi9EsEkefpkvPktz0Azud ZU0orNJkgZjKinn+j/GQ178BG2/04wPkgHknreWrh4yxYr8onLUawf4R9zs1RS0XKXB8 D9gEf8Vt8o8vQ0fGyYgxbcYc9YxxCnT04bNHab26ehLVoMwUFnNMatQ9F6wVx+bXsrA5 e4W+wch7iZ6MQOwVmYK1VZonPp38xUMvAGO+s65GwQbFooUKZdFJA4YjMbd9bUz6YbVJ wVa7OkJY6+Tnz0CDtNJrMyBUft5PDU4iaXgsq0sLBdUyZOk95cOdT7Q3+jJFxrJJnj1K xWtw== 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 t18si15430519ejr.440.2019.10.16.06.44.46; Wed, 16 Oct 2019 06:45:09 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404285AbfJPJlt (ORCPT + 99 others); Wed, 16 Oct 2019 05:41:49 -0400 Received: from mga02.intel.com ([134.134.136.20]:9173 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391934AbfJPJlt (ORCPT ); Wed, 16 Oct 2019 05:41:49 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Oct 2019 02:41:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,303,1566889200"; d="scan'208";a="200007842" Received: from linux.intel.com ([10.54.29.200]) by orsmga006.jf.intel.com with ESMTP; 16 Oct 2019 02:41:46 -0700 Received: from [10.125.252.157] (abudanko-mobl.ccr.corp.intel.com [10.125.252.157]) by linux.intel.com (Postfix) with ESMTP id 476EC58048F; Wed, 16 Oct 2019 02:41:44 -0700 (PDT) From: Alexey Budankov Subject: [PATCH v2 0/4]: perf/core: fix restoring of Intel LBR call stack on a context switch Organization: Intel Corp. To: Peter Zijlstra Cc: Arnaldo Carvalho de Melo , Ingo Molnar , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Andi Kleen , Kan Liang , Stephane Eranian , Ian Rogers , Song Liu , linux-kernel Message-ID: <5964c7e9-ab6f-c0d0-3dca-31196606e337@linux.intel.com> Date: Wed, 16 Oct 2019 12:41:43 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Restore Intel LBR call stack from cloned inactive task perf context on a context switch. This change inherently addresses inconsistency in LBR call stack data provided on a sample in record profiling mode: $ perf record -N -B -T -R --call-graph lbr \ -e cpu/period=0xcdfe60,event=0x3c,name=\'CPU_CLK_UNHALTED.THREAD\'/Duk \ --clockid=monotonic_raw -- ./miniFE.x nx 25 ny 25 nz 25 Let's assume threads A, B, C belonging to the same process. B and C are siblings of A and their perf contexts are treated as equivalent. At some point B blocks on a futex (non preempt context switch). B's LBRs are preserved at B's perf context task_ctx_data and B's events are removed from PMU and disabled. B's perf context becomes inactive. Later C gets on a cpu, runs, gets profiled and eventually switches to the awaken but not yet running B. The optimized context switch path is executed swapping B's and C's task_ctx_data pointers at perf event contexts. So C's task_ctx_data will refer preserved B's LBRs on the following switch-in event. However, as far B's perf context is inactive there is no enabled events in there and B's task_ctx_data->lbr_callstack_users is equal to 0. When B gets on the cpu B's events reviving is skipped following the optimized context switch path and B's task_ctx_data->lbr_callstack_users remains 0. Thus B's LBR's are not restored by pmu sched_task() code called in the end of perf context switch-in callback for B. In the report that manifests as having short fragments of B's call stack, still tracked by LBR's HW between adjacent samples, but the whole thread call tree doesn't aggregate. The fix has been evaluated when profiling miniFE [1] (C++, OpenMP) workload running 64 threads on Intel Skylake EP(64 core, 2 sockets): $ perf report --call-graph callee,flat 5.3.0-rc6+ (tip perf/core) - fixed - 92.66% 82.64% miniFE.x libiomp5.so [.] _INTERNAL_25_______src_kmp_barrier_cpp_1d20fae8::__kmp_hyper_barrier_release - 69.14% _INTERNAL_25_______src_kmp_barrier_cpp_1d20fae8::__kmp_hyper_barrier_release __kmp_fork_barrier __kmp_launch_thread _INTERNAL_24_______src_z_Linux_util_c_3e0095e6::__kmp_launch_worker start_thread __clone - 21.89% _INTERNAL_25_______src_kmp_barrier_cpp_1d20fae8::__kmp_hyper_barrier_release __kmp_barrier __kmpc_reduce_nowait miniFE::cg_solve, miniFE::Vector, miniFE::matvec_std, miniFE::Vector, miniFE::Vector, miniFE::matvec_std, miniFE::Vector, miniFE::Vector, miniFE::matvec_std, miniFE::Vector, miniFE::Vector, miniFE::matvec_std, miniFE::Vector