Message ID | cee6d5cd-e15b-3bb1-f867-de467d96d6b5@arm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:cae8:0:b0:403:3b70:6f57 with SMTP id r8csp1107688vqu; Mon, 25 Sep 2023 03:27:07 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEaeLhl9Sgf+Q8M7jcHQgwjtD3dqSSqINd7UO4GSsB01zM9BtxrJ33DRjUAgMl5/tZCgqhv X-Received: by 2002:a17:902:da91:b0:1c3:6d97:e897 with SMTP id j17-20020a170902da9100b001c36d97e897mr7517909plx.5.1695637626899; Mon, 25 Sep 2023 03:27:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695637626; cv=none; d=google.com; s=arc-20160816; b=hsQw0UrDYGrs+ZJ8GMFfQ7MVlyIysUCFGjHLy8xhDQ82VQZoh+05gpQATFMQu9wGml AN/r74IrCAgtAoYHH3Itmz5eGU9ESzu7kw1H7QTObhp0IJuyan5A6Y51ICm+s3+nPTVL gKmEqBQAwDP3qXwr3T1rjFsM2UMgrOLtPP/ZYCtTTwa1fjnJQXHvuswbC4NyEkWLpa9j 0QhzZGo24qX5IdRFxZ51mcTt11KOcLtYJPxKogknuwZLP5b8lzuTMkXNkZRAPQ6SoECh yj2OinqEg3ml9EQAFTPdq83USYcI+GDBK4mpwKLv63l/ox7cLPGuo2jvtpAUrom30UAX BvUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:subject:from:to :content-language:user-agent:mime-version:date:message-id; bh=7jmQzucQesNURI0tgD7IKXKfViuz72Wn/e+jXWSRLs4=; fh=CdxfJoTtEF7L+03oKMvah47XwltM6ZzT4UGKO20Wwk8=; b=Cq+j7ifkn4C7NoPdyyWQYjZp8OAQ7J8rd/r/kvpqj+NjF+nbyuZkbNZ4y5q0YdMqKw lUfK++nJ6/2cgO2wZE+urHoR17BiNKziZYhQyFtpp+HZfZOzaRKdn4iSWpp+h7SlhHoA jc/oli3HF958eqIR54Nh2CxkYCGAxYbJRKTScsofQJ9OWE5onqnBfLKk5KSMdfWhaW6Z ZraIwc2Vh3wzhIgQxSIbXa8hFuO3JS0eNkCgU+ExGcQsguO01m1WCVeJkFmNCLST408y QQK3rbr7oXCPI920o3vMIk/AYk236ooiRO3xNga55R9xRsuTp86PJoqlBkMbMFw4DGqL /wnQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from lipwig.vger.email (lipwig.vger.email. [23.128.96.33]) by mx.google.com with ESMTPS id n14-20020a170903110e00b001bbcb3d9265si10189925plh.68.2023.09.25.03.27.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Sep 2023 03:27:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id DF52D81CEB35; Mon, 25 Sep 2023 03:14:12 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231132AbjIYKNw (ORCPT <rfc822;pusanteemu@gmail.com> + 29 others); Mon, 25 Sep 2023 06:13:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40726 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231548AbjIYKNc (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 25 Sep 2023 06:13:32 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D76DC2697; Mon, 25 Sep 2023 03:02:07 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C943ADA7; Mon, 25 Sep 2023 03:02:45 -0700 (PDT) Received: from [10.57.36.242] (unknown [10.57.36.242]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C39193F59C; Mon, 25 Sep 2023 03:02:06 -0700 (PDT) Message-ID: <cee6d5cd-e15b-3bb1-f867-de467d96d6b5@arm.com> Date: Mon, 25 Sep 2023 11:02:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Content-Language: en-US To: rostedt@goodmis.org, mhiramat@kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-doc@vger.kernel.org, zhengyejian1@huawei.com From: Christian Loehle <christian.loehle@arm.com> Subject: [PATCH] tracing: document buffer_size_kb more precisely Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Mon, 25 Sep 2023 03:14:12 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778004919930628232 X-GMAIL-MSGID: 1778004919930628232 |
Series |
tracing: document buffer_size_kb more precisely
|
|
Commit Message
Christian Loehle
Sept. 25, 2023, 10:02 a.m. UTC
buffer_size_kb no longer shows the requested amount, but the one that
is actually used internally for the ring buffer.
commit 6d98a0f2ac3c ("tracing: Set actual size after ring buffer resize")
changed the sysfs behavior such that value read will always show the
actual size, while previously it showed the size that was requested
through the sysfs interface, even if it was rounded up to fulfill
the request.
So the documentation can state that more precisely now.
Signed-off-by: Christian Loehle <christian.loehle@arm.com>
---
Documentation/trace/ftrace.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On 2023/9/25 18:02, Christian Loehle wrote: > buffer_size_kb no longer shows the requested amount, but the one that > is actually used internally for the ring buffer. > > commit 6d98a0f2ac3c ("tracing: Set actual size after ring buffer resize") > changed the sysfs behavior such that value read will always show the > actual size, while previously it showed the size that was requested > through the sysfs interface, even if it was rounded up to fulfill > the request. > So the documentation can state that more precisely now. > > Signed-off-by: Christian Loehle <christian.loehle@arm.com> > --- > Documentation/trace/ftrace.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst > index 23572f6697c0..2e066b3b6edc 100644 > --- a/Documentation/trace/ftrace.rst > +++ b/Documentation/trace/ftrace.rst > @@ -191,7 +191,7 @@ of ftrace. Here is a list of some of the key files: > A few extra pages may be allocated to accommodate buffer management > meta-data. If the last page allocated has room for more bytes > than requested, the rest of the page will be used, > - making the actual allocation bigger than requested or shown. > + making the actual allocation bigger than requested. Hi, the actual allocation should still be bigger than shown due to the loss of accuracy when doing unit conversion from bytes to kilobytes (see tracing_entries_read()). -- Thanks, Zheng Yejian > ( Note, the size may not be a multiple of the page size > due to buffer management meta-data. ) >
On 25/09/2023 12:44, Zheng Yejian wrote: > On 2023/9/25 18:02, Christian Loehle wrote: >> buffer_size_kb no longer shows the requested amount, but the one that >> is actually used internally for the ring buffer. >> >> commit 6d98a0f2ac3c ("tracing: Set actual size after ring buffer resize") >> changed the sysfs behavior such that value read will always show the >> actual size, while previously it showed the size that was requested >> through the sysfs interface, even if it was rounded up to fulfill >> the request. >> So the documentation can state that more precisely now. >> >> Signed-off-by: Christian Loehle <christian.loehle@arm.com> >> --- >> Documentation/trace/ftrace.rst | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst >> index 23572f6697c0..2e066b3b6edc 100644 >> --- a/Documentation/trace/ftrace.rst >> +++ b/Documentation/trace/ftrace.rst >> @@ -191,7 +191,7 @@ of ftrace. Here is a list of some of the key files: >> A few extra pages may be allocated to accommodate buffer management >> meta-data. If the last page allocated has room for more bytes >> than requested, the rest of the page will be used, >> - making the actual allocation bigger than requested or shown. >> + making the actual allocation bigger than requested. > > Hi, the actual allocation should still be bigger than shown due to the > loss of accuracy when doing unit conversion from bytes to kilobytes (see > tracing_entries_read()). > Right, the sysfs obviously only allows for KB aligned setting, but you're right. If set on the cmdline non-KB multiples are possible and accuracy is lost. Nevermind then. > -- > > Thanks, > Zheng Yejian > >> ( Note, the size may not be a multiple of the page size >> due to buffer management meta-data. ) >> >
On Tue, 26 Sep 2023 11:38:14 +0100 Christian Loehle <christian.loehle@arm.com> wrote: > >> @@ -191,7 +191,7 @@ of ftrace. Here is a list of some of the key files: > >> A few extra pages may be allocated to accommodate buffer management > >> meta-data. If the last page allocated has room for more bytes > >> than requested, the rest of the page will be used, > >> - making the actual allocation bigger than requested or shown. > >> + making the actual allocation bigger than requested. > > > > Hi, the actual allocation should still be bigger than shown due to the > > loss of accuracy when doing unit conversion from bytes to kilobytes (see > > tracing_entries_read()). > > > Right, the sysfs obviously only allows for KB aligned setting, but you're right. > If set on the cmdline non-KB multiples are possible and accuracy is lost. > Nevermind then. I'm assuming this patch can be dropped? -- Steve
On 02/10/2023 16:09, Steven Rostedt wrote: > On Tue, 26 Sep 2023 11:38:14 +0100 > Christian Loehle <christian.loehle@arm.com> wrote: > >>>> @@ -191,7 +191,7 @@ of ftrace. Here is a list of some of the key files: >>>> A few extra pages may be allocated to accommodate buffer management >>>> meta-data. If the last page allocated has room for more bytes >>>> than requested, the rest of the page will be used, >>>> - making the actual allocation bigger than requested or shown. >>>> + making the actual allocation bigger than requested. >>> >>> Hi, the actual allocation should still be bigger than shown due to the >>> loss of accuracy when doing unit conversion from bytes to kilobytes (see >>> tracing_entries_read()). >>> >> Right, the sysfs obviously only allows for KB aligned setting, but you're right. >> If set on the cmdline non-KB multiples are possible and accuracy is lost. >> Nevermind then. > > I'm assuming this patch can be dropped? > > -- Steve Yes please drop it, there's probably still some room for improvement for clarity, but this patch is not correct.
diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst index 23572f6697c0..2e066b3b6edc 100644 --- a/Documentation/trace/ftrace.rst +++ b/Documentation/trace/ftrace.rst @@ -191,7 +191,7 @@ of ftrace. Here is a list of some of the key files: A few extra pages may be allocated to accommodate buffer management meta-data. If the last page allocated has room for more bytes than requested, the rest of the page will be used, - making the actual allocation bigger than requested or shown. + making the actual allocation bigger than requested. ( Note, the size may not be a multiple of the page size due to buffer management meta-data. )