linux-trace-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Loehle <christian.loehle@arm.com>
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
Subject: [PATCH] tracing: document buffer_size_kb more precisely
Date: Mon, 25 Sep 2023 11:02:11 +0100	[thread overview]
Message-ID: <cee6d5cd-e15b-3bb1-f867-de467d96d6b5@arm.com> (raw)

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.
 	( Note, the size may not be a multiple of the page size
 	due to buffer management meta-data. )
 
-- 
2.34.1

             reply	other threads:[~2023-09-25 10:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-25 10:02 Christian Loehle [this message]
2023-09-25 11:44 ` [PATCH] tracing: document buffer_size_kb more precisely Zheng Yejian
2023-09-26 10:38   ` Christian Loehle
2023-10-02 15:09     ` Steven Rostedt
2023-10-03 15:01       ` Christian Loehle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cee6d5cd-e15b-3bb1-f867-de467d96d6b5@arm.com \
    --to=christian.loehle@arm.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=zhengyejian1@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).