From: Ingo Molnar <mingo@kernel.org>
To: wenyang.linux@foxmail.com
Cc: Steven Rostedt <rostedt@goodmis.org>,
Andrew Morton <akpm@linux-foundation.org>,
Oleg Nesterov <oleg@redhat.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Christian Brauner <brauner@kernel.org>,
Mel Gorman <mgorman@techsingularity.net>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org
Subject: Re: [RESEND PATCH v3] exit: move trace_sched_process_exit earlier in do_exit()
Date: Sat, 30 Mar 2024 11:28:12 +0100 [thread overview]
Message-ID: <ZgfpPFYmvSg4WC+c@gmail.com> (raw)
In-Reply-To: <tencent_F5D82FE0B9A0CA9C3A29C866F225FD915905@qq.com>
* wenyang.linux@foxmail.com <wenyang.linux@foxmail.com> wrote:
> From: Wen Yang <wenyang.linux@foxmail.com>
>
> In a safety critical system, when some processes exit abnormally, it
> is hoped that prompt information can be reported to the monitor as
> soon as possible.
If this event is so critical to catch, a probe can be put on do_exit().
This will be superior to your patch, because it will notify about the
event even sooner.
> Commit 2d4bcf886e42 ("exit: Remove profile_task_exit &
> profile_munmap") simplified the code, but also removed
> profile_task_exit(), which may prevent third-party kernel modules
> from detecting process exits timely.
Could you point out an example of such third-party kernel modules, and
why we should care about them?
> Compared to adding an extra tracking point, it is better to move the
> existing trace_sched_process_exit() earlier in do_exit(), since any
> tracer interested in knowing the point where a task is really
> reclaimed is trace_sched_process_free() called from
> delayed_put_task_struct().[1]
I disagree, I think this scheduler tracepoint should be moved even
*later* in the exit sequence, and be combined with
sched_autogroup_exit_task(), so that the scheduler only has a single
exit-notification callback in essence.
Until this is all done cleanly no tree should pick up this change:
NAKed-by: Ingo Molnar <mingo@kernel.org>
Thanks,
Ingo
prev parent reply other threads:[~2024-03-30 10:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-30 2:52 [RESEND PATCH v3] exit: move trace_sched_process_exit earlier in do_exit() wenyang.linux
2024-03-30 10:28 ` Ingo Molnar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZgfpPFYmvSg4WC+c@gmail.com \
--to=mingo@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mgorman@techsingularity.net \
--cc=mhiramat@kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=wenyang.linux@foxmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.