[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230905121744.538b92cc@gandalf.local.home>
Date: Tue, 5 Sep 2023 12:17:44 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Zheng Yejian <zhengyejian1@...wei.com>
Cc: <mhiramat@...nel.org>, <linux-kernel@...r.kernel.org>,
<linux-trace-kernel@...r.kernel.org>, <yeweihua4@...wei.com>
Subject: Re: [PATCH] tracing: Fix unexpected ring buffer expand by instance
On Tue, 5 Sep 2023 20:17:14 +0800
Zheng Yejian <zhengyejian1@...wei.com> wrote:
> The ring buffer of global_trace is set to the minimum size in
> order to save memory on boot up and then it will be expand when
> some trace feature enabled.
>
> However currently operations under an instance can also cause
> global_trace ring buffer being expanded, and the expanded memory
> would be wasted if global_trace then not being used.
>
> See following case, we enable 'sched_switch' event in instance 'A', then
> ring buffer of global_trace is unexpectedly expanded to be 1410KB, also
> the '(expanded: 1408)' from 'buffer_size_kb' of instance is confusing.
>
> # cd /sys/kernel/tracing
> # mkdir instances/A
> # cat buffer_size_kb
> 7 (expanded: 1408)
> # cat instances/A/buffer_size_kb
> 1410 (expanded: 1408)
> # echo sched:sched_switch > instances/A/set_event
> # cat buffer_size_kb
> 1410
> # cat instances/A/buffer_size_kb
> 1410
>
> To fix it, we can:
> - Make 'ring_buffer_expanded' as a member of 'struct trace_array';
> - Make 'ring_buffer_expanded' of instance is defaultly true,
> global_trace is defaultly false;
> - In order not to expose 'global_trace' outside of file
> 'kernel/trace/trace.c', introduce trace_set_ring_buffer_expanded()
> to set 'ring_buffer_expanded' as 'true';
> - Pass the expected trace_array to tracing_update_buffers().
>
> Signed-off-by: Zheng Yejian <zhengyejian1@...wei.com>
> ---
> kernel/trace/trace.c | 46 ++++++++++++++++++++-----------------
> kernel/trace/trace.h | 9 ++++++--
> kernel/trace/trace_events.c | 22 ++++++++++--------
> 3 files changed, 44 insertions(+), 33 deletions(-)
>
Looks good, but as the merge window is still open, it will need to wait
till it is closed to be reviewed.
Thanks,
-- Steve
Powered by blists - more mailing lists