Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp3980153img; Tue, 26 Mar 2019 00:03:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqwET5L67j7YZUWOkRe1MmMLOfrnExdpCQLs5CcF76RCvGLPVIjMKQfGNSMM6gKiHjk6THYk X-Received: by 2002:a17:902:864b:: with SMTP id y11mr19428187plt.1.1553583816036; Tue, 26 Mar 2019 00:03:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553583816; cv=none; d=google.com; s=arc-20160816; b=Ox/IouvPdLFgN0yxTf9Gw7LNQNOgjhfu+E9o+2gb2xWV1AABbPB3YOcAZwheKD6dVK UIOuFmdy4YfvVao2lnlwANI0vMz4iUL8xIL3++ElWCWals0jNIMSTTja9LAcNZG8Aquq oLoOgPM+f1EHPfA++2w1NojXHKo75/6M0LQk6xB67iFGIllE3nekENcmJsN6uj8cbZrm G5A+QPpWCcQUnPm3msgIUYP2OUP1AN1QukUepBSTvHtzh1JbYCHuIepDeHsqxK8XTBaI FoNm0aqkN+1+3qi2VB6ZfOyg7rngqTF2TehzVH+RawYUuboeHhBREM74UPclIXQYGbLO PNVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=TmuXoampxIABWv9bUHTWei/zaUHedydsOx+hwEoGd18=; b=TIgzXHTjPEpPuFALmgvM9yYxvKeiRvmZlVpJGWF6hYjhrq1tCBNDuix7lNm8g7R9N9 A7fJSHI+gq7NBOBTQCKDhNsUMWSkjKwDEZ35Whk1ZSuZw0XwLw+Pc/gSA5TP6D/SzaGE 184B2NL/ewblBw3xSumB5F8b/Kd9CEbqsUE0kNr7HzEXh7gwcSaXyw+VJyOK2OEYCo2K sQ2EAf8XMQHWCAEaOAe7V6cCJ03QHyRBGPldu0P2sYP4jDl3+bRvszO1t2KZ7SxnrEee Ebza9FjRgAE9UPCq0U2nfaFymK9u7qzIdxLUne+wTwHni6dGlIFn9o+Mt+tCXmKZEbcq JTMw== 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 b12si15338804plr.285.2019.03.26.00.03.20; Tue, 26 Mar 2019 00:03:36 -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 S1730625AbfCZHCq (ORCPT + 99 others); Tue, 26 Mar 2019 03:02:46 -0400 Received: from mga07.intel.com ([134.134.136.100]:10826 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726042AbfCZHCp (ORCPT ); Tue, 26 Mar 2019 03:02:45 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Mar 2019 00:02:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,271,1549958400"; d="scan'208";a="128698117" Received: from um.fi.intel.com (HELO localhost) ([10.237.72.178]) by orsmga008.jf.intel.com with ESMTP; 26 Mar 2019 00:02:42 -0700 From: Alexander Shishkin To: Ben Gainey , "mingo\@kernel.org" , "peterz\@infradead.org" , "acme\@redhat.com" , Will Deacon Cc: "linux-arm-kernel\@lists.infradead.org" , "linux-kernel\@vger.kernel.org" , alexander.shishkin@linux.intel.com Subject: Re: BUG in "perf: Suppress AUX/OVERWRITE records"? In-Reply-To: References: Date: Tue, 26 Mar 2019 09:02:40 +0200 Message-ID: <87k1gm86en.fsf@ashishki-desk.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ben Gainey writes: > Hi all > > Regarding commit 1627314fb54a33ebd23bd08f2e215eaed0f44712 "perf: > Suppress AUX/OVERWRITE records", I have found that I no longer receive > PERF_RECORD_AUX on context switch when collecting data from the arm_spe > PMU driver. This is because, on context switch, the arm_spe driver > calls perf_aux_output_end with `handle->aux_flags == 0`, failing the > test added in this commit. > > This is a problem as it means when capturing data for multiple threads > (using perf_event_open) where AUX data is written to a per-cpu buffer, > I can no longer accurately attribute SPE AUX data to an individual > thread. Sounds like PERF_RECORD_SWITCH should be sufficient for your purposes, have you considered that? > If I read the intent of the commit as to remove OVERWRITE AUX records, > then it seems the added if condition is incorrect and should probably > be formulated as: > > if ((handle->aux_flags & ~(u64)PERF_AUX_FLAG_OVERWRITE) || !handle- >>aux_flags) > > Is this correct (and would you like a patch?), or is my use of > PERF_RECORD_AUX incorrect in this case? No, the point of AUX records is to communicate useful things about the data in AUX buffer. It was an unintentional side effect that it also happened to coincide with context switches in the overwrite mode. Thanks, -- Alex