All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent Donnefort <vdonnefort@google.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: mhiramat@kernel.org, linux-kernel@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org, kernel-team@android.com
Subject: Re: [PATCH v8 0/2] Introducing trace buffer mapping by user-space
Date: Wed, 20 Dec 2023 13:06:06 +0000	[thread overview]
Message-ID: <ZYLmvmzLOBfrrsSu@google.com> (raw)
In-Reply-To: <20231219153924.2ff9c132@gandalf.local.home>

On Tue, Dec 19, 2023 at 03:39:24PM -0500, Steven Rostedt wrote:
> On Tue, 19 Dec 2023 18:45:54 +0000
> Vincent Donnefort <vdonnefort@google.com> wrote:
> 
> > The tracing ring-buffers can be stored on disk or sent to network
> > without any copy via splice. However the later doesn't allow real time
> > processing of the traces. A solution is to give userspace direct access
> > to the ring-buffer pages via a mapping. An application can now become a
> > consumer of the ring-buffer, in a similar fashion to what trace_pipe
> > offers.
> > 
> > Attached to this cover letter an example of consuming read for a
> > ring-buffer, using libtracefs.
> > 
> 
> I'm still testing this, but I needed to add this patch to fix two bugs. One
> is that you are calling rb_wakeup_waiters() for both the buffer and the
> cpu_buffer, and it needs to know which one to use the container_of() macro.
> 
> The other is a "goto unlock" that unlocks two locks where only one was taken.
> 
> -- Steve
> 
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 35f3736f660b..987ad7bd1e8b 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -389,6 +389,7 @@ struct rb_irq_work {
>  	bool				waiters_pending;
>  	bool				full_waiters_pending;
>  	bool				wakeup_full;
> +	bool				is_cpu_buffer;
>  };
>  
>  /*
> @@ -771,10 +772,20 @@ static void rb_update_meta_page(struct ring_buffer_per_cpu *cpu_buffer)
>  static void rb_wake_up_waiters(struct irq_work *work)
>  {
>  	struct rb_irq_work *rbwork = container_of(work, struct rb_irq_work, work);
> -	struct ring_buffer_per_cpu *cpu_buffer =
> -		container_of(rbwork, struct ring_buffer_per_cpu, irq_work);
> +	struct ring_buffer_per_cpu *cpu_buffer;
> +	struct trace_buffer *buffer;
> +	int cpu;
>  
> -	rb_update_meta_page(cpu_buffer);
> +	if (rbwork->is_cpu_buffer) {
> +		cpu_buffer = container_of(rbwork, struct ring_buffer_per_cpu, irq_work);
> +		rb_update_meta_page(cpu_buffer);
> +	} else {
> +		buffer = container_of(rbwork, struct trace_buffer, irq_work);
> +		for_each_buffer_cpu(buffer, cpu) {
> +			cpu_buffer = buffer->buffers[cpu];
> +			rb_update_meta_page(cpu_buffer);
> +		}
> +	}

Arg, somehow never reproduced the problem :-\. I suppose you need to cat
trace/trace_pipe and mmap(trace/cpuX/trace_pipe) at the same time?

Updating the meta-page is only useful if the reader we are waking up is a
user-space one, which would only happen with the cpu_buffer version of this
function. We could limit the update of the meta_page only to this case?

>  
>  	wake_up_all(&rbwork->waiters);
>  	if (rbwork->full_waiters_pending || rbwork->wakeup_full) {
> @@ -1569,6 +1580,7 @@ rb_allocate_cpu_buffer(struct trace_buffer *buffer, long nr_pages, int cpu)
>  	init_waitqueue_head(&cpu_buffer->irq_work.waiters);
>  	init_waitqueue_head(&cpu_buffer->irq_work.full_waiters);
>  	mutex_init(&cpu_buffer->mapping_lock);
> +	cpu_buffer->irq_work.is_cpu_buffer = true;
>  
>  	bpage = kzalloc_node(ALIGN(sizeof(*bpage), cache_line_size()),
>  			    GFP_KERNEL, cpu_to_node(cpu));
> @@ -6209,7 +6221,8 @@ int ring_buffer_map(struct trace_buffer *buffer, int cpu)
>  
>  	if (cpu_buffer->mapped) {
>  		WRITE_ONCE(cpu_buffer->mapped, cpu_buffer->mapped + 1);
> -		goto unlock;
> +		mutex_unlock(&cpu_buffer->mapping_lock);
> +		return 0;
>  	}
>  
>  	/* prevent another thread from changing buffer sizes */

  reply	other threads:[~2023-12-20 13:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-19 18:45 [PATCH v8 0/2] Introducing trace buffer mapping by user-space Vincent Donnefort
2023-12-19 18:45 ` [PATCH v8 1/2] ring-buffer: Introducing ring-buffer mapping functions Vincent Donnefort
2023-12-19 18:45 ` [PATCH v8 2/2] tracing: Allow user-space mapping of the ring-buffer Vincent Donnefort
2023-12-19 20:39 ` [PATCH v8 0/2] Introducing trace buffer mapping by user-space Steven Rostedt
2023-12-20 13:06   ` Vincent Donnefort [this message]
2023-12-20 13:29     ` Steven Rostedt
2023-12-20 13:49       ` Vincent Donnefort
2023-12-20 16:02         ` Steven Rostedt

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=ZYLmvmzLOBfrrsSu@google.com \
    --to=vdonnefort@google.com \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=rostedt@goodmis.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.