[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250910124509.14e2c69f@gandalf.local.home>
Date: Wed, 10 Sep 2025 12:45:09 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Vincent Donnefort <vdonnefort@...gle.com>
Cc: mhiramat@...nel.org, mathieu.desnoyers@...icios.com,
linux-trace-kernel@...r.kernel.org, maz@...nel.org, oliver.upton@...ux.dev,
joey.gouly@....com, suzuki.poulose@....com, yuzenghui@...wei.com,
kvmarm@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
jstultz@...gle.com, qperret@...gle.com, will@...nel.org,
aneesh.kumar@...nel.org, kernel-team@...roid.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 04/24] tracing: Add reset to trace remotes
On Wed, 10 Sep 2025 10:45:05 +0100
Vincent Donnefort <vdonnefort@...gle.com> wrote:
> > If we are gonna keep the "trace" file, let's make sure it's fully
> > implemented.
>
> I was more worry about the ring-buffer page order that can be reshuffled on each
> swap_reader_page(), making the page links useless in the kernel. Ideally, the
> meta-page would keep the page ID order somewhere.
Yeah, internally we could keep the order of the pages. Shouldn't be too
hard, as the swapping happens by the kernel.
>
> Alternatively, we could walk all the buffer pages to read the timestamp and
> re-create the order but that sounds quite cumbersome.
No, having a separate array of the order is probably what we want. Then
every swap_reader_page() will update the array. The trace iterator could
simply walk that array.
-- Steve
Powered by blists - more mailing lists