From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752552AbcBEJ0r (ORCPT ); Fri, 5 Feb 2016 04:26:47 -0500 Received: from mail-wm0-f65.google.com ([74.125.82.65]:36607 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752271AbcBEJ0n (ORCPT ); Fri, 5 Feb 2016 04:26:43 -0500 Date: Fri, 5 Feb 2016 10:26:40 +0100 From: Michal Hocko To: David Rientjes Cc: Andrew Morton , Mel Gorman , Tetsuo Handa , Oleg Nesterov , Linus Torvalds , Hugh Dickins , Andrea Argangeli , Rik van Riel , linux-mm@kvack.org, LKML Subject: Re: [PATCH 4/5] mm, oom_reaper: report success/failure Message-ID: <20160205092640.GA5477@dhcp22.suse.cz> References: <1454505240-23446-1-git-send-email-mhocko@kernel.org> <1454505240-23446-5-git-send-email-mhocko@kernel.org> <20160204064636.GD8581@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 04-02-16 14:31:26, David Rientjes wrote: > On Thu, 4 Feb 2016, Michal Hocko wrote: > > > > I think it would be helpful to show anon-rss after reaping, however, so we > > > can compare to the previous anon-rss that was reported. And, I agree that > > > leaving behind a message in the kernel log that reaping has been > > > successful is worthwhile. So this line should just show what anon-rss is > > > after reaping and make it clear that this is not the memory reaped. > > > > Does > > "oom_reaper: reaped process %d (%s) current memory anon-rss:%lukB, file-rss:%lukB, shmem-rss:%lukB " > > > > sound any better? > > oom_reaper: reaped process %d (%s), now anon-rss:%lukB > > would probably be better until additional support is added to do other > kinds of reaping other than just primarily heap. This should help to > quantify the exact amount of memory that could be reaped (or otherwise > unmapped) iff oom_reaper has to get involved rather than fluctations that > have nothing to do with it. --- >>From 402090df64de7f80d7d045b0b17e860220837fa6 Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Fri, 5 Feb 2016 10:24:23 +0100 Subject: [PATCH] mm-oom_reaper-report-success-failure-fix update the log message to be more specific Signed-off-by: Michal Hocko --- mm/oom_kill.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/oom_kill.c b/mm/oom_kill.c index 87d644c97ac9..ca61e6cfae52 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -479,7 +479,7 @@ static bool __oom_reap_task(struct task_struct *tsk) } } tlb_finish_mmu(&tlb, 0, -1); - pr_info("oom_reaper: reaped process :%d (%s) anon-rss:%lukB, file-rss:%lukB, shmem-rss:%lulB\n", + pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB, file-rss:%lukB, shmem-rss:%lulB\n", task_pid_nr(tsk), tsk->comm, K(get_mm_counter(mm, MM_ANONPAGES)), K(get_mm_counter(mm, MM_FILEPAGES)), -- 2.7.0 -- Michal Hocko SUSE Labs