On Fri, Aug 07, 2026 at 10:45:26AM -0400, Steven Rostedt wrote: > On Fri, 7 Aug 2026 10:43:12 +0100 > Vincent Donnefort <[email protected]> wrote: > > > On Fri, Aug 07, 2026 at 09:14:26AM +0100, Vincent Donnefort wrote: > > > On Fri, Aug 07, 2026 at 11:18:08AM +0900, Masami Hiramatsu wrote: > > > > On Thu, 6 Aug 2026 22:13:01 +0100 > > > > Vincent Donnefort <[email protected]> wrote: > > > > > > > > > Dynamically resizing a persistent ring buffer is not possible. Disable > > > > > the feature. > > > > > > > > Is it true? Of course there is meaningless to resize the persistent > > > > ring buffer (because it makes the buffer none-persistent), we are > > > > currently > > > > allows user to resize it (like for resizing unused persistent ring > > > > buffer) > > > > > > __rb_allocate_pages() in ring_buffer_resize() would call for a persistent > > > buffer > > > rb_range_buffer(), which IIUC, is just reusing the same ring buffer pages > > > as the > > > one already in the persistent buffer. > > > > I have just tried and if reducing the size works, increasing fails in both > > rb_set_head_page() and rb_insert_pages() with a warning, which I believe is > > expected. > > > > We could improve that, but it feels like it is a lot of work for a > > meaningless > > feature which we should just disable? > > Resizing a persistent ring buffer to a smaller size may be allowed, but I > see no point in increasing the size. Making it smaller should allow us to > give back a portion of the persistent ring buffer for general usage. > > -- Steve
While I see the appeal to reclaim that memory, I don't think we have any good interface for that. There is no nice way to get the list of pages that have been freed and we have no control over what part of the ring-buffer is removed. Also, as this memory is from a reserved-range, is there really a way to re-inject it into the buddy allocator? Perhaps what would make sense for resizing would be to support a CMA pool as a persistent buffer? -- Vincent
