All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: "Frank A. Cancio Bello" <frank@generalsoftwareinc.com>
Cc: Ingo Molnar <mingo@redhat.com>, Jonathan Corbet <corbet@lwn.net>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	joel@joelfernandes.org, saiprakash.ranjan@codeaurora.org
Subject: Re: [RFC 1/2] docs: ftrace: Clarify the RAM impact of buffer_size_kb
Date: Wed, 13 Nov 2019 11:37:30 -0500	[thread overview]
Message-ID: <20191113113730.213ddd72@gandalf.local.home> (raw)
In-Reply-To: <0e4a803c3e24140172855748b4a275c31920e208.1573661658.git.frank@generalsoftwareinc.com>

On Wed, 13 Nov 2019 11:32:36 -0500
"Frank A. Cancio Bello" <frank@generalsoftwareinc.com> wrote:

> The current text could mislead the user into believing that the number
> of pages allocated by each CPU ring buffer is calculated by the round
> up of the division: buffer_size_kb / PAGE_SIZE.
> 
> Clarify that the number of pages allocated is the round up of the
> division: buffer_size_kb / (PAGE_SIZE - BUF_PAGE_HDR_SIZE). Add an
> example that shows how the number of pages allocated could be off by
> 5 pages more compared with how the current text suggests it should be.
> 
> Suggested-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> Signed-off-by: Frank A. Cancio Bello <frank@generalsoftwareinc.com>
> ---
>  Documentation/trace/ftrace.rst | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
> index e3060eedb22d..ec2c4eff95a6 100644
> --- a/Documentation/trace/ftrace.rst
> +++ b/Documentation/trace/ftrace.rst
> @@ -188,8 +188,17 @@ of ftrace. Here is a list of some of the key files:
>  	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.
> -	( Note, the size may not be a multiple of the page size
> -	due to buffer management meta-data. )

The above is not untrue ;-)

> +
> +        The number of pages allocated for each CPU buffer may not
> +        be the same than the round up of the division:
> +        buffer_size_kb / PAGE_SIZE. This is because part of each page is
> +        used to store a page header with metadata. E.g. with
> +        buffer_size_kb=4096 (kilobytes), a PAGE_SIZE=4096 bytes and a
> +        BUF_PAGE_HDR_SIZE=16 bytes (BUF_PAGE_HDR_SIZE is the size of the
> +        page header with metadata) the number of pages allocated for each
> +        CPU buffer is 1029, not 1024. The formula for calculating the
> +        number of pages allocated for each CPU buffer is the round up of:
> +        buffer_size_kb / (PAGE_SIZE - BUF_PAGE_HDR_SIZE).

I have no problem with this patch, but the concern of documenting the
implementation here, which will most likely not be updated if the
implementation is ever changed, which is why I was vague to begin with.

But it may never be changed as that code has been like that for a
decade now.

-- Steve


>  
>  	Buffer sizes for individual CPUs may vary
>  	(see "per_cpu/cpu0/buffer_size_kb" below), and if they do


  reply	other threads:[~2019-11-13 16:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-13 16:31 [RFC 0/2] docs: ftrace: Clarify the RAM impact of buffer_size_kb Frank A. Cancio Bello
2019-11-13 16:32 ` [RFC 1/2] " Frank A. Cancio Bello
2019-11-13 16:37   ` Steven Rostedt [this message]
2019-11-14 20:20     ` Joel Fernandes
2019-11-14 21:36       ` Steven Rostedt
2019-11-15  4:24         ` Frank A. Cancio Bello
2019-11-15 13:30           ` Steven Rostedt
2019-11-15 15:59             ` Frank A. Cancio Bello
2019-11-15 16:03               ` Steven Rostedt
2019-11-13 16:33 ` [RFC 2/2] ** do not apply this patch ** Just for illustration purposes Frank A. Cancio Bello
2019-11-13 21:06   ` kbuild test robot
2019-11-16 10:01   ` kbuild test robot

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=20191113113730.213ddd72@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=corbet@lwn.net \
    --cc=frank@generalsoftwareinc.com \
    --cc=joel@joelfernandes.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=saiprakash.ranjan@codeaurora.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.