Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp562438pxf; Thu, 8 Apr 2021 08:33:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyJn6b7HHDSK0pcVBqbdAwniFEPk0UpGO1eLCZ6JwsLlrKhx89n4rNa8PBdepSuIGSmuMGl X-Received: by 2002:a2e:5416:: with SMTP id i22mr3733957ljb.403.1617896024489; Thu, 08 Apr 2021 08:33:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617896024; cv=none; d=google.com; s=arc-20160816; b=zLEi21EuvnqG1C6KSkbAmx4mxrLNCzO4RkC4oQF/FUE0B7fDHm5q+c8cD2IK7IP+aD 221Wug0Afqh25SwEOOaBmDTqd2/fHaK56ZwUF3fRsC2lqmsaXWBO/IW6LoF9DKWKRLNu PmhJoAhcN3nlR21fV2Dyy8AUDgxuG4etrt9asinXU95+MDXVIrdavvLKfBgvUXRrMj1B gcTn9EekZovmJU2VGUe0IPW7PIkrc0+7WOoFD9kDBU/vXW0Ch4phjIyo3aoml0KmUbSc Fwkui4rowQmGcHbwDTrbvIWHzrhqDraUfSVqc+RJuyuaoVyYS75j8zX4egEncoL8ceVI RTWw== 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=AvrDg3Xsbe8xkt8wkHzh6ukgG3nvZ2gLcaoquBGrh/s=; b=ZD7QiFCEXGK2m6jqjKT6wLBrgFd+RQc+n+V1yHXSC0Bk1D0Ng8FgA4ORpoYdA4jFLR Yro1Yz3EHA7iLVcQxVqkqD60r6eOZevzGuSJxar3xbR50vTMsatylEK92KqOUH1Lce7x qSuUla2uU1E4ukooZyfvUJwL7QZmT6IctUWOSuUSS9CErqBJgvM2Ol0O4Qrbv56FPk7r 0SN7iGI5YSG+aEmcxu0jhCbqvrDvEs6KffJUrvYk4AlqDNcIqQCmLxJnukO9dRiwWhUn HCNBkUST7wg3UkTgg4cA6QitKb8FDqS3w9mt/VAFZ02nR4jXyW192CVd7AuKUlgn+mBI 2t6Q== 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 y25si22797696ejb.626.2021.04.08.08.33.21; Thu, 08 Apr 2021 08:33:44 -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 S231878AbhDHPcY (ORCPT + 99 others); Thu, 8 Apr 2021 11:32:24 -0400 Received: from mga04.intel.com ([192.55.52.120]:22953 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232200AbhDHPcW (ORCPT ); Thu, 8 Apr 2021 11:32:22 -0400 IronPort-SDR: /jGr9UpEUiZXT16CZurb2c+fU2XsWT2mu8SEHcQwDJ5Sb+/dch6JDr00FEoVCwoJR540EXRwMT OfEftTBwDFYA== X-IronPort-AV: E=McAfee;i="6000,8403,9948"; a="191412401" X-IronPort-AV: E=Sophos;i="5.82,206,1613462400"; d="scan'208";a="191412401" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2021 08:32:11 -0700 IronPort-SDR: HrgZ+UPlK0iS9+SpWhX+He/x97IHaPsta2J1B7FNpOVoj5TDB8QDD6Z0B4yHvwror4GcJil6/3 Hjh+TJ7+cZoA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,206,1613462400"; d="scan'208";a="415820756" Received: from black.fi.intel.com (HELO black.fi.intel.com.) ([10.237.72.28]) by fmsmga008.fm.intel.com with ESMTP; 08 Apr 2021 08:32:08 -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 2/2] perf intel-pt: Use aux_watermark Date: Thu, 8 Apr 2021 18:31:59 +0300 Message-Id: <20210408153159.81880-3-alexander.shishkin@linux.intel.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20210408153159.81880-1-alexander.shishkin@linux.intel.com> References: <20210408153159.81880-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 | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/tools/perf/arch/x86/util/intel-pt.c b/tools/perf/arch/x86/util/intel-pt.c index a6420c647959..d00707faf547 100644 --- a/tools/perf/arch/x86/util/intel-pt.c +++ b/tools/perf/arch/x86/util/intel-pt.c @@ -776,6 +776,10 @@ static int intel_pt_recording_options(struct auxtrace_record *itr, } } + if (opts->full_auxtrace) + intel_pt_evsel->core.attr.aux_watermark = + opts->auxtrace_mmap_pages / 4 * page_size; + intel_pt_parse_terms(intel_pt_pmu->name, &intel_pt_pmu->format, "tsc", &tsc_bit); -- 2.30.2