On Tue 30-05-17 14:33:35, Roman Gushchin wrote: > On Tue, May 30, 2017 at 02:34:16PM +0200, Michal Hocko wrote: > > On Tue 30-05-17 13:05:32, Roman Gushchin wrote: > > > Add tracepoints to simplify the debugging of the oom reaper code. > > > > > > Trace the following events: > > > 1) a process is marked as an oom victim, > > > 2) a process is added to the oom reaper list, > > > 3) the oom reaper starts reaping process's mm, > > > 4) the oom reaper finished reaping, > > > 5) the oom reaper skips reaping. > > > > I am not against but could you explain why the current printks are not > > sufficient? We do not have any explicit printk for the 2) and 3) but > > are those really necessary? > > We also don't have any printks for 1) and 2) if, for, instance, we call > out_of_memory() and task_will_free_mem(current) returns true. > > > > > In other words could you describe the situation when you found these > > tracepoints more useful than what the kernel log offers already? > > During my work on cgroup-aware OOM killer and some issues discovered > in process (which are described in https://lkml.org/lkml/2017/5/17/542; > most important problem fixed by Tetsuo), I've found an existing debug output > insufficient and sometimes too bulky. > > Suggested traces allowed me to debug issues like I've met (double invocation > of oom_reaper, etc) much easier. Please describe those and examples how the new tracepoints will be useful in the changelog. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
