[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1602041428120.29117@chino.kir.corp.google.com>
Date: Thu, 4 Feb 2016 14:31:26 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: Michal Hocko <mhocko@...nel.org>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Mel Gorman <mgorman@...e.de>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Oleg Nesterov <oleg@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Hugh Dickins <hughd@...gle.com>,
Andrea Argangeli <andrea@...nel.org>,
Rik van Riel <riel@...hat.com>, linux-mm@...ck.org,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/5] mm, oom_reaper: report success/failure
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.
Powered by blists - more mailing lists