Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp115301pxb; Wed, 14 Apr 2021 10:41:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxA2LyxmzTtmLq/9PB1YK8WODuSWtj5DdoGkQRIeWvp6ABCDEefQk/lfIdBOEzHVUGmP7EC X-Received: by 2002:a17:906:a449:: with SMTP id cb9mr54109ejb.118.1618422111431; Wed, 14 Apr 2021 10:41:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618422111; cv=none; d=google.com; s=arc-20160816; b=iocNqdAJKXVYgMLWZZEN76st0nxG1xCvHn6KMl39sDXslfvAKMthA1itz7AcaSdPn1 hYePZjXaTx3hDHFsvPK4Wkigmb81iZ777d/VCnTOw4iwJkNPRVgPlwiPsc0tWsWn2Wp2 0y+x3SQCMH1OmnqfjZ6UlFVziDUuzGc58fBkb5Q+SMQMrmyl7P6PDNW6hNcePqhi3fU6 ESXhF2XOUmQJHUT14vZynOpFq79SUUqSxa3Gj4Tb1ZZx0TVKXhlGFp+CVyLRKodh/Wpd TKVuq4bzIQObNeykRr3mg7iPUAILWs9Pqc6sY/7xvanlr5pvBXhs8lYapcFU9iwN3hAj j93A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :ironport-sdr:ironport-sdr; bh=mOTcE3qHVVfHR6/ACyeWWOShQMurqp2mjeBEwh8Kivs=; b=HMmlhjFqwLl5eJZfxxWD87s3mDtCkNLavVayERkb/Xl8xwJf4FP2vGAH85dYIkl6of P54AsyVrX7X8vQ6UNbgvA3VPos3FTL2sfAM8pNV3k/se4sXzcZweX1rHllqNzhitlTxw KRLimgI2RzghKWpKxE/Y2Ig27H8UOwmPTeral87W/SLT2PcD6l0I+donttjqauaVRhKq M6C8vVyXHIx6lJGEY/Lhxw90n57WxLOCQ6/FkjXojlVcfFlJTLXlEzuL5gLMBblSQ/J9 nC9rrBcKuA8EGgFb0P9k8g2bx9+a42ywBzpIlk6WkkC/uNljHEvZ9eDYJ6nErNH9Ynz5 7wtQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id pg17si1538830ejb.474.2021.04.14.10.41.26; Wed, 14 Apr 2021 10:41:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1352433AbhDNPxq (ORCPT + 99 others); Wed, 14 Apr 2021 11:53:46 -0400 Received: from mga05.intel.com ([192.55.52.43]:37627 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352442AbhDNPxK (ORCPT ); Wed, 14 Apr 2021 11:53:10 -0400 IronPort-SDR: YgqaTmEZuTha6PLsJKYH54ZctbJlusWAn83cXt4+Kj2v1Qvy7MJQndVRBlCRpR3OEIMu68uDdH 3AMy4gGLVN9A== X-IronPort-AV: E=McAfee;i="6200,9189,9954"; a="279979739" X-IronPort-AV: E=Sophos;i="5.82,222,1613462400"; d="scan'208";a="279979739" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Apr 2021 08:51:02 -0700 IronPort-SDR: jfbCfrwYhwQxqKkQsYOLHpPCHplyHhu3S+5x/t1gLornIi/I/MxrFhHJPPky0gB+0+EkWgCKi5 tbU7Z6IyPmjQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,222,1613462400"; d="scan'208";a="399226043" Received: from black.fi.intel.com (HELO black.fi.intel.com.) ([10.237.72.28]) by orsmga002.jf.intel.com with ESMTP; 14 Apr 2021 08:50:59 -0700 From: Alexander Shishkin To: Peter Zijlstra , Arnaldo Carvalho de Melo , adrian.hunter@intel.com Cc: Ingo Molnar , linux-kernel@vger.kernel.org, Jiri Olsa , Mathieu Poirier , Alexander Shishkin Subject: [PATCH v1 2/2] perf intel-pt: Use aux_watermark Date: Wed, 14 Apr 2021 18:49:55 +0300 Message-Id: <20210414154955.49603-3-alexander.shishkin@linux.intel.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20210414154955.49603-1-alexander.shishkin@linux.intel.com> References: <20210414154955.49603-1-alexander.shishkin@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Turns out, the default setting of attr.aux_watermark to half of the total buffer size is not very useful, especially with smaller buffers. The problem is that, after half of the buffer is filled up, the kernel updates ->aux_head and sets up the next "transaction", while observing that ->aux_tail is still zero (as userspace haven't had the chance to update it), meaning that the trace will have to stop at the end of this second "transaction". This means, for example, that the second PERF_RECORD_AUX in every trace comes with TRUNCATED flag set. Setting attr.aux_watermark to quarter of the buffer gives enough space for the ->aux_tail update to be observed and prevents the data loss. The obligatory before/after showcase: > # perf_before record -e intel_pt//u -m,8 uname > Linux > [ perf record: Woken up 6 times to write data ] > Warning: > AUX data lost 4 times out of 10! > > [ perf record: Captured and wrote 0.099 MB perf.data ] > # perf record -e intel_pt//u -m,8 uname > Linux > [ perf record: Woken up 4 times to write data ] > [ perf record: Captured and wrote 0.039 MB perf.data ] The effect is still visible with large workloads and large buffers, although less pronounced. Signed-off-by: Alexander Shishkin --- tools/perf/arch/x86/util/intel-pt.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/tools/perf/arch/x86/util/intel-pt.c b/tools/perf/arch/x86/util/intel-pt.c index a6420c647959..6df0dc00d73a 100644 --- a/tools/perf/arch/x86/util/intel-pt.c +++ b/tools/perf/arch/x86/util/intel-pt.c @@ -776,6 +776,12 @@ static int intel_pt_recording_options(struct auxtrace_record *itr, } } + if (!opts->auxtrace_snapshot_mode && !opts->auxtrace_sample_mode) { + u32 aux_watermark = opts->auxtrace_mmap_pages * page_size / 4; + + intel_pt_evsel->core.attr.aux_watermark = aux_watermark; + } + intel_pt_parse_terms(intel_pt_pmu->name, &intel_pt_pmu->format, "tsc", &tsc_bit); -- 2.30.2