On Mon, 10 Aug 2026 09:56:53 +0100 Vincent Donnefort <[email protected]> wrote:
> > > > > > What would need to be done is: > > > > > > 1. calculate the new size needed to accommodate all the CPU buffers. > > > 2. Split them up within the new size region. > > > 3. Then free the remaining pages. > > > > > > Obviously, access to the buffer from readers and writers will need to be > > > prohibited while this is happening. > > That would mean losing all the data on the buffer? Actually the trace_remote > needs to teardown the whole buffer before the size is modified. Perhaps if > something similar is done for the persistent buffer, trace_remote could > benefit. Yes it would remove all data in the buffer. If you are going to resize the buffer, you need to be OK with loss of data. It's not going to be a gentle operation. > > > > > Hmm, I think we also need to record the size of persistent ring buffer at > > initialization. The buffer size (number of pages are calculated by the > > size of reserved memory, which is defined in the kernel cmdline. Oh right. If we do the change, it needs to be stored because of the checks done at boot up. It checks to make sure that the size on boot up is the same as when it was running. If we remove pages, that needs to be passed to the meta data so that on reboot it can detect that. > > Could we store in ring_buffer_cpu_meta::buffers that the page is gone and must > be skipped to re-create the ring-buffer? Not just skipped, but the amount "saved" will be different. Now we need to know that the amount of the ring buffer is different than the kernel command line. What I would have is this: 1. Bootup wit persistent ring buffer at size X. 2. At run time, shrink buffer to size Y where Y < X 2a. Rewrite buffer with new total size and divvy up the per CPU buffers 2b. Write the new size in the cpu meta data 3. Start tracing 4. Crash/reboot 5. Check meta data checksum, and if match and size is different, divvy up by given size. 5a. Record the currently saved size. 6. Show size as "original cmdline size" (why? see next step) 7. Start tracing 7a. Rewrite buffer with the origin cmdline size 7b. Start actual tracing That is, the resize is only applicable for the boot where the resize happened. The output of the resize will still be visible, but the buffers will go back to the original cmdline size as soon as tracing begins again. If the user resizes again, then jump back to 2a. The resize is only to allow a user to reclaim persistent buffer memory if they do not think they need to save as much after boot up. -- Steve
