| Message ID | 20230804072945.85731-3-xueshuai@linux.alibaba.com |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org>
Delivered-To: ouuuleilei@gmail.com
Received: by 2002:a05:612c:44a:b0:3f2:4152:657d with SMTP id ez10csp109318vqb;
Fri, 4 Aug 2023 01:23:59 -0700 (PDT)
X-Google-Smtp-Source:
AGHT+IFH9nwkNDwhFaV6Zwf0j307DWDCBs3agYSnhYJliN8rwyM2UX69dxTXyko9cXyzelIhQQ5V
X-Received: by 2002:a05:6358:249f:b0:13a:9d5:356a with SMTP id
m31-20020a056358249f00b0013a09d5356amr97719rwc.21.1691137439108;
Fri, 04 Aug 2023 01:23:59 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1691137439; cv=none;
d=google.com; s=arc-20160816;
b=wEH16DOdzDdBzzj3HggZ5+hK/VXyM+e4lUoxFe+uUrU5EsoLyvUmYtn00AU7Q4FH0V
6GqNSzs3cAiEQEPQnwleJibUgDebvhahn2NNikea/4V6QtxLtZpzwvHbZE0ZW9ArcsAx
VBY9rLRTbZkyL1HmoWo7IqOg4KcuMeU137Qr3N7QClVqPeP+X9c1aGGc92S5iUrQ6/Nb
+dxMsvTMXJZhsfJE4yewZE4m5a9wvCtE9y3JcG6yIFD0s0qWUpHSU/KwsLR8sCyhng32
lAZYy5kBAEN6Ez6dY0GtWkEN0Egph14DnLwkjaB8YwwMedLhdppCorbi0kL3X+xAk1o+
E1wQ==
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;
bh=DMRXbyZgZ5S0K4812xQbLo0ye892sTPJ6ZLWwDaT7Hc=;
fh=YBikRTpR9zYoVYjuRUV1Fnixx8IEvJqVUBSmWl5mLFU=;
b=hJtQrlsucrA0Zf5kXUgWlUOSRN08k4S0iuHF924zU5n4kf7tEzPGRnQJdLx46VGx5r
OoU63Sdw3e8kV8+NGv77bdtT9ZproYxPveAxKyusjJqcWzp9Ka4Zc/MBGIPvAS0vLroV
/VrnvqVRU1DltnQzkX35PV67uatRzAihQ5HynfA+gAAVYMksqc/JDa/7idR8dvAkqDth
EQe+RRYzaFCTV9hzJtKFZ0P3sONFVfKsWlDNkNX/gndm24fw5jqZdzqrioLB+91kltdl
+yvd1dAopI0DC5jQI3FPzkY9UKFyX1j6yKbnYrALveBMA9n5QqqVBMJ+rnCJRcJxAz/Y
kRGg==
ARC-Authentication-Results: i=1; mx.google.com;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com
Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20])
by mx.google.com with ESMTP id
c17-20020a63da11000000b0054481da6ee5si1407619pgh.418.2023.08.04.01.23.45;
Fri, 04 Aug 2023 01:23:59 -0700 (PDT)
Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
client-ip=2620:137:e000::1:20;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S234353AbjHDHc3 (ORCPT <rfc822;sukrut.bellary@gmail.com>
+ 99 others); Fri, 4 Aug 2023 03:32:29 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35108 "EHLO
lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S233944AbjHDHcD (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Fri, 4 Aug 2023 03:32:03 -0400
Received: from out30-132.freemail.mail.aliyun.com
(out30-132.freemail.mail.aliyun.com [115.124.30.132])
by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BDCC14EE0;
Fri, 4 Aug 2023 00:31:03 -0700 (PDT)
X-Alimail-AntiSpam:
AC=PASS;BC=-1|-1;BR=01201311R641e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046051;MF=xueshuai@linux.alibaba.com;NM=1;PH=DS;RN=16;SR=0;TI=SMTPD_---0Vp.c2KL_1691134195;
Received: from localhost.localdomain(mailfrom:xueshuai@linux.alibaba.com
fp:SMTPD_---0Vp.c2KL_1691134195)
by smtp.aliyun-inc.com;
Fri, 04 Aug 2023 15:29:56 +0800
From: Shuai Xue <xueshuai@linux.alibaba.com>
To: alexander.shishkin@linux.intel.com, peterz@infradead.org,
james.clark@arm.com, leo.yan@linaro.org
Cc: mingo@redhat.com, baolin.wang@linux.alibaba.com, acme@kernel.org,
mark.rutland@arm.com, jolsa@kernel.org, namhyung@kernel.org,
irogers@google.com, adrian.hunter@intel.com,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
nathan@kernel.org, bpf@vger.kernel.org
Subject: [PATCH v4 2/2] perf record: Update docs regarding the maximum
limitation of AUX area
Date: Fri, 4 Aug 2023 15:29:45 +0800
Message-Id: <20230804072945.85731-3-xueshuai@linux.alibaba.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20230804072945.85731-1-xueshuai@linux.alibaba.com>
References: <20230804072945.85731-1-xueshuai@linux.alibaba.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00,
ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,
UNPARSEABLE_RELAY,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no
version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-getmail-retrieved-from-mailbox: INBOX
X-GMAIL-THRID: 1773286131013991158
X-GMAIL-MSGID: 1773286131013991158
|
| Series |
perf/core: Bail out early if the request AUX area is out of bound
|
|
Commit Message
Shuai Xue
Aug. 4, 2023, 7:29 a.m. UTC
The maximum AUX area is limited by the page size of the system. Update
the documentation to reflect this.
Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
---
tools/perf/Documentation/perf-record.txt | 3 +++
1 file changed, 3 insertions(+)
Comments
On Fri, Aug 04, 2023 at 03:29:45PM +0800, Shuai Xue wrote: > The maximum AUX area is limited by the page size of the system. Update > the documentation to reflect this. > > Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com> > --- > tools/perf/Documentation/perf-record.txt | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/tools/perf/Documentation/perf-record.txt b/tools/perf/Documentation/perf-record.txt > index 680396c56bd1..b0ee7b63da0e 100644 > --- a/tools/perf/Documentation/perf-record.txt > +++ b/tools/perf/Documentation/perf-record.txt > @@ -292,6 +292,9 @@ OPTIONS > Also, by adding a comma, the number of mmap pages for AUX > area tracing can be specified. > > + The maximum AUX area is limited by the page size of the system. For > + example with 4K pages configured, the maximum is 2GiB. > + This statement is incorrect as it fails to give out prerequisites. E.g., on Arm64, for 4KiB, 16KiB or 64KiB base page size, different page size has different default values for MAX_ORDER. Furthermore, MAX_ORDER can be set by config ARCH_FORCE_MAX_ORDER, thus we cannot arbitrarily say the maximum allocation size is 2GiB for 4KiB page size. Maybe we could consider to use a formula to present the avaliable maximum buffer size: PAGE_SIZE << MAX_ORDER ( ---------------------- ) * PAGE_SIZE sizeof(page_pointer) PAGE_SIZE << MAX_ORDER : the size of maximal physically contiguous allocations, which is the maximum size can be allocated by slab/slub. Thanks, Leo > -g:: > Enables call-graph (stack chain/backtrace) recording for both > kernel space and user space. > -- > 2.39.3 >
On 2023/8/4 16:46, Leo Yan wrote: > On Fri, Aug 04, 2023 at 03:29:45PM +0800, Shuai Xue wrote: >> The maximum AUX area is limited by the page size of the system. Update >> the documentation to reflect this. >> >> Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com> >> --- >> tools/perf/Documentation/perf-record.txt | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/tools/perf/Documentation/perf-record.txt b/tools/perf/Documentation/perf-record.txt >> index 680396c56bd1..b0ee7b63da0e 100644 >> --- a/tools/perf/Documentation/perf-record.txt >> +++ b/tools/perf/Documentation/perf-record.txt >> @@ -292,6 +292,9 @@ OPTIONS >> Also, by adding a comma, the number of mmap pages for AUX >> area tracing can be specified. >> >> + The maximum AUX area is limited by the page size of the system. For >> + example with 4K pages configured, the maximum is 2GiB. >> + > > This statement is incorrect as it fails to give out prerequisites. > > E.g., on Arm64, for 4KiB, 16KiB or 64KiB base page size, different page > size has different default values for MAX_ORDER. Furthermore, MAX_ORDER > can be set by config ARCH_FORCE_MAX_ORDER, thus we cannot arbitrarily > say the maximum allocation size is 2GiB for 4KiB page size. > Hi, Leo, You are right, thank you for point this out. Maybe we could consider to use a formula to present the avaliable > maximum buffer size: > > PAGE_SIZE << MAX_ORDER > ( ---------------------- ) * PAGE_SIZE > sizeof(page_pointer) > > PAGE_SIZE << MAX_ORDER : the size of maximal physically > contiguous allocations, which is the maximum size can be > allocated by slab/slub. I agree that a formula to present that limitation is more accurate. But as @James commented in last v3, "Minor nit: I wouldn't expect a Perf tool user to know what "MAX_ORDER" is", how about to keep both: The maximum AUX area is limited by the maximum physically contiguous memory allocated from slab/slub. It can be calculated with following formula: PAGE_SIZE << MAX_ORDER ( ---------------------- ) * PAGE_SIZE sizeof(page_pointer) For example with 4K pages and MAX_ORDER=10 configured, the maximum AUX area is 2GiB. Thank you. Best Regards, Shuai
diff --git a/tools/perf/Documentation/perf-record.txt b/tools/perf/Documentation/perf-record.txt index 680396c56bd1..b0ee7b63da0e 100644 --- a/tools/perf/Documentation/perf-record.txt +++ b/tools/perf/Documentation/perf-record.txt @@ -292,6 +292,9 @@ OPTIONS Also, by adding a comma, the number of mmap pages for AUX area tracing can be specified. + The maximum AUX area is limited by the page size of the system. For + example with 4K pages configured, the maximum is 2GiB. + -g:: Enables call-graph (stack chain/backtrace) recording for both kernel space and user space.