Linus,
tracing ring buffer updates for v6.10:
- Add ring_buffer memory mappings
The tracing ring buffer was created based on being mostly used with the
splice system call. It is broken up into page ordered sub-buffers and the
reader swaps a new sub-buffer with an existing sub-buffer that's part
of the write buffer. It then has total access to the swapped out
sub-buffer and can do copyless movements of the memory into other mediums
(file system, network, etc).
The buffer is great for passing around the ring buffer contents in the
kernel, but is not so good for when the consumer is the user space task
itself.
A new interface is added that allows user space to memory map the ring
buffer. It will get all the write sub-buffers as well as reader sub-buffer
(that is not written to). It can send an ioctl to change which sub-buffer
is the new reader sub-buffer.
The ring buffer is read only to user space. It only needs to call the
ioctl when it is finished with a sub-buffer and needs a new sub-buffer
that the writer will not write over.
A self test program was also created for testing and can be used as
an example for the interface to user space. The libtracefs (external
to the kernel) also has code that interacts with this, although it is
disabled until the interface is in a official release. It can be enabled
by compiling the library with a special flag. This was used for testing
applications that perform better with the buffer being mapped.
Memory mapped buffers have limitations. The main one is that it can not be
used with the snapshot logic. If the buffer is mapped, snapshots will be
disabled. If any logic is set to trigger snapshots on a buffer, that
buffer will not be allowed to be mapped.
- Changes since last pull request:
https://lore.kernel.org/all/[email protected]/
All the pages of the ring buffer are mapped at the mmap() system call
instead of paging them in when they are accessed. The VMA page flags
have been updated and the mappings are done via vm_insert_pages().
I'd like to thank both Mike Rapoport and David Hildenbrand for their
review of these patches to make sure they are doing things correctly
from a memory management point of view.
Please pull the latest trace-ringbuffer-v6.10 tree, which can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
trace-ringbuffer-v6.10
Tag SHA1: 61407f35944db217cadb6a520906d52668d6d212
Head SHA1: b9c6820f029abaabbc37646093866aa730ca0928
Steven Rostedt (Google) (2):
ring-buffer: Have mmapped ring buffer keep track of missed events
ring-buffer: Add cast to unsigned long addr passed to virt_to_page()
Vincent Donnefort (5):
ring-buffer: Allocate sub-buffers with __GFP_COMP
ring-buffer: Introducing ring-buffer mapping functions
tracing: Allow user-space mapping of the ring-buffer
Documentation: tracing: Add ring-buffer mapping
ring-buffer/selftest: Add ring-buffer mapping test
----
Documentation/trace/index.rst | 1 +
Documentation/trace/ring-buffer-map.rst | 106 ++++++
include/linux/ring_buffer.h | 6 +
include/uapi/linux/trace_mmap.h | 48 +++
kernel/trace/ring_buffer.c | 471 ++++++++++++++++++++++++-
kernel/trace/trace.c | 104 +++++-
kernel/trace/trace.h | 1 +
tools/testing/selftests/ring-buffer/.gitignore | 1 +
tools/testing/selftests/ring-buffer/Makefile | 8 +
tools/testing/selftests/ring-buffer/config | 2 +
tools/testing/selftests/ring-buffer/map_test.c | 294 +++++++++++++++
11 files changed, 1026 insertions(+), 16 deletions(-)
create mode 100644 Documentation/trace/ring-buffer-map.rst
create mode 100644 include/uapi/linux/trace_mmap.h
create mode 100644 tools/testing/selftests/ring-buffer/.gitignore
create mode 100644 tools/testing/selftests/ring-buffer/Makefile
create mode 100644 tools/testing/selftests/ring-buffer/config
create mode 100644 tools/testing/selftests/ring-buffer/map_test.c
---------------------------
The pull request you sent on Thu, 16 May 2024 12:33:48 -0400:
> git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git trace-ringbuffer-v6.10
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/53683e408013407848bd598da15641b2f0979351
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html