From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751670AbdE3Np7 (ORCPT ); Tue, 30 May 2017 09:45:59 -0400 Received: from mx2.suse.de ([195.135.220.15]:45053 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750952AbdE3Np4 (ORCPT ); Tue, 30 May 2017 09:45:56 -0400 Date: Tue, 30 May 2017 15:45:53 +0200 From: Michal Hocko To: Roman Gushchin Cc: Tetsuo Handa , Johannes Weiner , Vladimir Davydov , kernel-team@fb.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] mm,oom: add tracepoints for oom reaper-related events Message-ID: <20170530134552.GI7969@dhcp22.suse.cz> References: <1496145932-18636-1-git-send-email-guro@fb.com> <20170530123415.GF7969@dhcp22.suse.cz> <20170530133335.GB28148@castle> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170530133335.GB28148@castle> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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