[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250206102949.65493416@gandalf.local.home>
Date: Thu, 6 Feb 2025 10:29:49 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: "Masami Hiramatsu (Google)" <mhiramat@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org, Mark
Rutland <mark.rutland@....com>, Mathieu Desnoyers
<mathieu.desnoyers@...icios.com>, Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 6/8] tracing: Have persistent trace instances save
module addresses
On Thu, 6 Feb 2025 17:26:42 +0900
Masami Hiramatsu (Google) <mhiramat@...nel.org> wrote:
> This maybe too frequently scan the module because the update_last_data() is
> called when;
> - change tracer (this maybe OK)
> - update "set_event"
> - write 1 to "enable" under events
> - change pid filter
> - etc.
>
> Once it is scanned, it should not scan again, but update by module
> callback, because usually events are enabled individually (thus
> write 1 to "event" can happen multiple time online).
>
> I think we can move this after TRACE_ARRAY_FL_LAST_BOOT check,
> if TRACE_ARRAY_FL_LAST_BOOT flag is set, that flag should be cleared
> with updating the tscratch, and the flag is not set, we can skip updating
> the scratch.
No, because we could enable it, disable it, and then the user could be
adding and removing modules all day long, and we only add and do not remove
(I do have a patch that does remove them).
But we can do the same check as patch 8 does, and only do this if the
tracer wasn't already active.
-- Steve
Powered by blists - more mailing lists