From: Steven Rostedt <rostedt@goodmis.org>
To: Vincent Donnefort <vdonnefort@google.com>
Cc: Linux Trace Devel <linux-trace-devel@vger.kernel.org>
Subject: Re: [PATCH] libtracefs: Add ring buffer memory mapping APIs
Date: Fri, 5 Jan 2024 15:11:45 -0500 [thread overview]
Message-ID: <20240105151145.55996b48@gandalf.local.home> (raw)
In-Reply-To: <20240105123111.02dd9915@gandalf.local.home>
On Fri, 5 Jan 2024 12:31:11 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> Hmm, but looking at how the code currently works without mapping, it looks
> like it would do the read again anyway assuming that the kbuf was
> completely read before reading again. Perhaps it would make the logic
> simpler to assume that the buffer was completely read before this gets
> called again. That is, we could have it do:
Now I remember why I did it the other way. This is called to get the
kbuffer after it is mapped. That is, the first time we call this,
kbuf->curr will be zero, and we do not want to call the ioctl(). If we do,
we just threw away all the events currently loaded on the kbuf.
That is, the code does this:
tcpu = tracefs_cpu_open_mapped(NULL, cpu, 0);
// Here the memory is already mapped, and a kbuf is loaded.
mapped = tracefs_cpu_is_mapped(tcpu);
if (!mapped)
printf("Was not able to map, falling back to buffered read\n");
while ((kbuf = mapped ? tracefs_cpu_read_buf(tcpu, true) :
// The tracefs_cpu_read_buf() will call the trace_mmap_load_subbuf().
// That is, it must check if kbuf has left over data and return that.
// If it does the ioctl() here, it will throw out what it loaded in the
// initial mapping.
tracefs_cpu_buffered_read_buf(tcpu, true))) {
read_page(tep, kbuf);
}
-- Steve
>
> if (data != kbuffer_subbuffer(kbuf)) {
> kbuffer_load_subbuffer(kbuf, data);
> return 1;
> }
>
> if (ioctl(tmap->fd, TRACE_MMAP_IOCTL_GET_READER) < 0)
> return -1;
>
> if (id != tmap->map->reader.id) {
> /* New page, just reload it */
> data = tmap->data + tmap->map->subbuf_size * id;
> kbuffer_load_subbuffer(kbuf, data);
> return 1;
> }
>
> /*
> * Perhaps the reader page had a write that added
> * more data.
> */
> kbuffer_refresh(kbuf);
>
> /* Are there still events to read? */
> return kbuffer_curr_size(kbuf) ? 1 : 0;
next prev parent reply other threads:[~2024-01-05 20:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-29 1:11 [PATCH] libtracefs: Add ring buffer memory mapping APIs Steven Rostedt
2024-01-05 9:17 ` Vincent Donnefort
2024-01-05 13:41 ` Steven Rostedt
2024-01-05 14:25 ` Vincent Donnefort
2024-01-05 17:31 ` Steven Rostedt
2024-01-05 18:23 ` Vincent Donnefort
2024-01-05 19:00 ` Steven Rostedt
2024-01-05 20:11 ` Steven Rostedt [this message]
2024-01-05 20:22 ` Steven Rostedt
-- strict thread matches above, loose matches on Subject: below --
2024-01-05 20:29 Steven Rostedt
2024-01-08 14:25 ` Vincent Donnefort
2024-01-08 17:16 ` Steven Rostedt
2024-01-08 17:34 ` Vincent Donnefort
2024-01-23 9:52 ` Vincent Donnefort
2024-01-23 15:15 ` 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=20240105151145.55996b48@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=linux-trace-devel@vger.kernel.org \
--cc=vdonnefort@google.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).