Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 2 Jul 2018 12:22:36 +0200
From:   Michal Hocko <mhocko@kernel.org>
To:     ufo19890607@gmail.com
Cc:     akpm@linux-foundation.org, rientjes@google.com,
        kirill.shutemov@linux.intel.com, aarcange@redhat.com,
        penguin-kernel@i-love.sakura.ne.jp, guro@fb.com,
        yang.s@alibaba-inc.com, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, yuzhoujian@didichuxing.com
Subject: Re: [PATCH v11 2/2] Add the missing information in dump_header
Message-ID: <20180702102236.GE19043@dhcp22.suse.cz>
References: <1530376739-20459-1-git-send-email-ufo19890607@gmail.com>
 <1530376739-20459-2-git-send-email-ufo19890607@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1530376739-20459-2-git-send-email-ufo19890607@gmail.com>
User-Agent: Mutt/1.10.0 (2018-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sun 01-07-18 00:38:59, ufo19890607@gmail.com wrote:
> From: yuzhoujian <yuzhoujian@didichuxing.com>
> 
> Add a new func mem_cgroup_print_oom_context to print missing information
> for the system-wide oom report which includes the oom memcg that has
> reached its limit, task memcg that contains the killed task.

A proper changelog should contain the motivation. It is trivial to see
what the patch does from the diff. The motivation is less clear. What
about the followig
"
The current oom report doesn't display victim's memcg context during the
global OOM situation. While this information is not strictly needed it
can be really usefule for containerized environments to see which
container has lost a process (+ add more arguments I am just guessing
from your not really specific statements). Now that we have a single
line for the oom context we can trivially add both the oom memcg (this
can be either global_oom or a specific memcg which hits its hard limits)
and task_memcg which is the victim's memcg.
"
-- 
Michal Hocko
SUSE Labs