All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent Donnefort <vdonnefort@google.com>
To: Xiang Gao <gxxa03070307@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Donggeun Yoo <donggeunyoo.kernel@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lorenzo Stoakes <ljs@kernel.org>, gao xu <gaoxu2@honor.com>,
	yinchuang1@xiaomi.com, linux-trace-kernel@vger.kernel.org,
	linux-kernel@vger.kernel.org, Xiang Gao <gaoxiang17@xiaomi.com>
Subject: Re: [PATCH v5 1/4] ring-buffer: add ring_buffer_memory_size()
Date: Sat, 14 Nov 2026 14:17:29 +0000	[thread overview]
Message-ID: <avhteUQSrWPFuQ3a@google.com> (raw)
In-Reply-To: <20261105140221.44614-2-gaoxiang17@xiaomi.com>

On Thu, Nov 05, 2026 at 10:02:18PM +0800, Xiang Gao wrote:
> Add a helper to report the page memory consumed by a ring buffer for a
> given CPU. It accounts for the data sub-buffers, the reader page, the
> cached read page, and the mmap metadata page. Unlike
> ring_buffer_capacity(), which reports the usable data capacity, this
> reports the full pages allocated to the buffer.
> 
> The function is generic and returns a size for any buffer type, so
> callers that need the memory footprint of remote or persistent buffers
> can use it as well.
> 
> Signed-off-by: Xiang Gao <gaoxiang17@xiaomi.com>
> ---
>  include/linux/ring_buffer.h |  1 +
>  kernel/trace/ring_buffer.c  | 37 +++++++++++++++++++++++++++++++++++++
>  2 files changed, 38 insertions(+)
> 
> diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h
> index 649b2276b557..e83e94623e76 100644
> --- a/include/linux/ring_buffer.h
> +++ b/include/linux/ring_buffer.h
> @@ -174,6 +174,7 @@ int ring_buffer_iter_empty(struct ring_buffer_iter *iter);
>  bool ring_buffer_iter_dropped(struct ring_buffer_iter *iter);
>  
>  unsigned long ring_buffer_capacity(struct trace_buffer *buffer, int cpu);
> +unsigned long ring_buffer_memory_size(struct trace_buffer *buffer, int cpu);
>  unsigned long ring_buffer_max_event_size(struct trace_buffer *buffer);
>  
>  void ring_buffer_reset_cpu(struct trace_buffer *buffer, int cpu);
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 1fd28a72e6ee..0396ec671998 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -6566,6 +6566,43 @@ unsigned long ring_buffer_capacity(struct trace_buffer *buffer, int cpu)
>  }
>  EXPORT_SYMBOL_GPL(ring_buffer_capacity);
>  
> +/**
> + * ring_buffer_memory_size - return the memory used by the buffer (in bytes)
> + * @buffer: The ring buffer.
> + * @cpu: The CPU to get ring buffer memory from.
> + *
> + * Returns the page memory consumed by @cpu, including the data sub-buffers,
> + * the reader page, the cached read page, and the mmap metadata page. Unlike
> + * ring_buffer_capacity(), which reports the usable data capacity, this
> + * accounts for the full pages allocated to the buffer.
> + */
> +unsigned long ring_buffer_memory_size(struct trace_buffer *buffer, int cpu)

memory_size() may be confusing because we don't account for all the other
kmalloc() allocations. 

I have also just realised, do we really need yet another accessor? With the
existing ones:

  nr_pages = ring_buffer_capacity(buffer, cpu) / (ring_buffer_subbuf_size_get(buffer) - BUF_PAGE_HDR_SIZE);

(Alhough there's a race with ring_buffer_subbuf_size_set() to be resolved!!!)

And if the caller knows if a cpu_buffer is a remote, or a persistent buffer, it
can just add nr_pages++.

This only leaves free_page unaccounted for. But does that really matter if the
other solution would be to have a very racy free_page accounting?

-- 
Vincent

> +{
> +	struct ring_buffer_per_cpu *cpu_buffer;
> +	unsigned long subbuf_size;
> +	unsigned long size;
> +
> +	if (!cpumask_test_cpu(cpu, buffer->cpumask))
> +		return 0;
> +
> +	cpu_buffer = buffer->buffers[cpu];
> +	subbuf_size = PAGE_SIZE << READ_ONCE(buffer->subbuf_order);
> +
> +	/* Data sub-buffers plus the reader page. */
> +	size = (READ_ONCE(cpu_buffer->nr_pages) + 1) * subbuf_size;
> +
> +	/* The cached read page, if present, is a full sub-buffer page. */
> +	if (READ_ONCE(cpu_buffer->free_page.data))
> +		size += subbuf_size;
> +
> +	/* The mmap metadata page is a single system page. */
> +	if (READ_ONCE(cpu_buffer->meta_page))
> +		size += PAGE_SIZE;
> +
> +	return size;
> +}
> +EXPORT_SYMBOL_GPL(ring_buffer_memory_size);
> +
>  /**
>   * ring_buffer_max_event_size - return the max data size of an event
>   * @buffer: The ring buffer.
> -- 
> 2.34.1
> 

  reply	other threads:[~2026-11-14 14:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-05 14:02 [PATCH v5 0/4] tracing: add ring-buffer memory usage statistics Xiang Gao
2026-11-05 14:02 ` [PATCH v5 1/4] ring-buffer: add ring_buffer_memory_size() Xiang Gao
2026-11-14 14:17   ` Vincent Donnefort [this message]
2026-11-05 14:02 ` [PATCH v5 2/4] tracing: add aggregate buffer memory usage statistics Xiang Gao
2026-11-05 14:02 ` [PATCH v5 3/4] tracing: add per-CPU " Xiang Gao
2026-11-05 14:12   ` sashiko-bot
2026-11-05 14:02 ` [PATCH v5 4/4] Documentation: document trace_stats memory_usage_kb Xiang Gao

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=avhteUQSrWPFuQ3a@google.com \
    --to=vdonnefort@google.com \
    --cc=donggeunyoo.kernel@gmail.com \
    --cc=gaoxiang17@xiaomi.com \
    --cc=gaoxu2@honor.com \
    --cc=gxxa03070307@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=yinchuang1@xiaomi.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 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.