From: Michal Hocko <mhocko@suse.com>
To: Pratyush Brahma <quic_pbrahma@quicinc.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
quic_charante@quicinc.com, quic_pkondeti@quicinc.com
Subject: Re: [PATCH v2] mm: oom_kill: add trace logs in process_mrelease() system call
Date: Mon, 19 Sep 2022 16:43:04 +0200 [thread overview]
Message-ID: <Yyh/+HqwIXAnTARc@dhcp22.suse.cz> (raw)
In-Reply-To: <1326361c-44c3-d2e0-c7a9-1e4b3e84ab6e@quicinc.com>
On Wed 17-08-22 12:17:22, Pratyush Brahma wrote:
>
> On 17-08-2022 06:05, Andrew Morton wrote:
> > On Tue, 16 Aug 2022 11:30:17 +0530 Pratyush Brahma <pbrahma@qti.qualcomm.com> wrote:
> >
> > > The process_mrelease() system call[1] is used to release the memory of
> > > a dying process from the context of the caller, which is similar to and
> > > uses the functions of the oom reaper logic. There exists trace logs for
> > > a process when reaped by the oom reaper. Just extend the same to when
> > > done by the process_mrelease() system call.
> > Why? Please describe in full detail the end-user value of this change.
>
> This patch provides information on how much memory is freed from a process
> which is being reaped. Adding trace events in the process_mrelease() path when
> process is being reaped would enable more holistic debug as it happens in
> oom_reap_task_mm() currently.
>
> This extends the debug functionality for the events as described in [1] to
> the process_mrelease() system call. Now the coverage of trace events is complete.
Yes this is all nice but why it is needed to extend process_mrelease to
be in par with the oom path? OOM path happens out of direct control of
while this is under direct control of the caller. So why do we need more
debugging data from the kernel? The information dumped by the tracing
can be queried already by other means and much more extensibly.
> [1]
> https://lore.kernel.org/all/20170530185231.GA13412@castle/T/#u
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2022-09-19 14:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-16 6:00 [PATCH v2] mm: oom_kill: add trace logs in process_mrelease() system call Pratyush Brahma
2022-08-17 0:35 ` Andrew Morton
2022-08-17 6:47 ` Pratyush Brahma
2022-09-19 14:43 ` Michal Hocko [this message]
2022-08-17 16:02 ` Andrew Morton
2022-08-18 4:45 ` Pratyush Brahma
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=Yyh/+HqwIXAnTARc@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=quic_charante@quicinc.com \
--cc=quic_pbrahma@quicinc.com \
--cc=quic_pkondeti@quicinc.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).