From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754718AbcHSC0P (ORCPT ); Thu, 18 Aug 2016 22:26:15 -0400 Received: from LGEAMRELO12.lge.com ([156.147.23.52]:60938 "EHLO lgeamrelo12.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753934AbcHSC0N (ORCPT ); Thu, 18 Aug 2016 22:26:13 -0400 X-Original-SENDERIP: 156.147.1.121 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Fri, 19 Aug 2016 11:26:34 +0900 From: Minchan Kim To: Michal Hocko Cc: Sonny Rao , Jann Horn , Robert Foss , corbet@lwn.net, Andrew Morton , Vlastimil Babka , Konstantin Khlebnikov , Hugh Dickins , Naoya Horiguchi , John Stultz , ross.zwisler@linux.intel.com, jmarchan@redhat.com, Johannes Weiner , Kees Cook , Al Viro , Cyrill Gorcunov , Robin Humble , David Rientjes , eric.engestrom@imgtec.com, Janis Danisevskis , calvinowens@fb.com, Alexey Dobriyan , "Kirill A. Shutemov" , ldufour@linux.vnet.ibm.com, linux-doc@vger.kernel.org, "linux-kernel@vger.kernel.org" , Ben Zhang , Bryan Freed , Filipe Brandenburger , Mateusz Guzik Subject: Re: [PACTH v2 0/3] Implement /proc//totmaps Message-ID: <20160819022634.GA14206@bbox> References: <20160816071243.GB5001@dhcp22.suse.cz> <336532d0-57f2-a430-d195-13c13f70e25a@collabora.com> <20160817082200.GA10547@dhcp22.suse.cz> <20160817093125.GA27782@pc.thejh.net> <20160817130320.GC20703@dhcp22.suse.cz> <20160818074433.GC30162@dhcp22.suse.cz> <20160818180104.GS30162@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160818180104.GS30162@dhcp22.suse.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Michal, On Thu, Aug 18, 2016 at 08:01:04PM +0200, Michal Hocko wrote: > On Thu 18-08-16 10:47:57, Sonny Rao wrote: > > On Thu, Aug 18, 2016 at 12:44 AM, Michal Hocko wrote: > > > On Wed 17-08-16 11:57:56, Sonny Rao wrote: > [...] > > >> 2) User space OOM handling -- we'd rather do a more graceful shutdown > > >> than let the kernel's OOM killer activate and need to gather this > > >> information and we'd like to be able to get this information to make > > >> the decision much faster than 400ms > > > > > > Global OOM handling in userspace is really dubious if you ask me. I > > > understand you want something better than SIGKILL and in fact this is > > > already possible with memory cgroup controller (btw. memcg will give > > > you a cheap access to rss, amount of shared, swapped out memory as > > > well). Anyway if you are getting close to the OOM your system will most > > > probably be really busy and chances are that also reading your new file > > > will take much more time. I am also not quite sure how is pss useful for > > > oom decisions. > > > > I mentioned it before, but based on experience RSS just isn't good > > enough -- there's too much sharing going on in our use case to make > > the correct decision based on RSS. If RSS were good enough, simply > > put, this patch wouldn't exist. > > But that doesn't answer my question, I am afraid. So how exactly do you > use pss for oom decisions? My case is not for OOM decision but I agree it would be great if we can get *fast* smap summary information. PSS is really great tool to figure out how processes consume memory more exactly rather than RSS. We have been used it for monitoring of memory for per-process. Although it is not used for OOM decision, it would be great if it is speed up because we don't want to spend many CPU time for just monitoring. For our usecase, we don't need AnonHugePages, ShmemPmdMapped, Shared_Hugetlb, Private_Hugetlb, KernelPageSize, MMUPageSize because we never enable THP and hugetlb. Additionally, Locked can be known via vma flags so we don't need it, either. Even, we don't need address range for just monitoring when we don't investigate in detail. Although they are not severe overhead, why does it emit the useless information? Even bloat day by day. :( With that, userspace tools should spend more time to parse which is pointless. Having said that, I'm not fan of creating new stat knob for that, either. How about appending summary information in the end of smap? So, monitoring users can just open the file and lseek to the (end - 1) and read the summary only. Thanks.