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@xxxxxxxxxxxxxxxx> 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
