From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Cyrus-Session-Id: sloti22d1t05-1135939-1523544432-2-7297744484883151925 X-Sieve: CMU Sieve 3.0 X-Spam-known-sender: no X-Spam-score: 0.0 X-Spam-hits: BAYES_00 -1.9, MAILING_LIST_MULTI -1, ME_NOAUTH 0.01, RCVD_IN_DNSWL_HI -5, LANGUAGES en, BAYES_USED global, SA_VERSION 3.4.0 X-Spam-source: IP='209.132.180.67', Host='vger.kernel.org', Country='US', FromHeader='org', MailFrom='org' X-Spam-charsets: plain='us-ascii' X-Resolved-to: greg@kroah.com X-Delivered-to: greg@kroah.com X-Mail-from: linux-api-owner@vger.kernel.org ARC-Seal: i=1; a=rsa-sha256; cv=none; d=messagingengine.com; s=fm2; t= 1523544431; b=uo92v2ZPEpxKtT9h486YYU9YgcTCqRvdPWNmnPRJmSikiexf1m 82aH1O3dt6NSSDLwtLwBMWBb9Bc7CEY9ASQHoNZ6ctpGpI/9+cztI+CaBjQwOLEt 0f3vBLegdEYOl8tCzARWN4kPwtH/bh4TdZgB/lSwMBppEb0bMgEqOeBHxALmy96Y iDEq9UIYPSktn9Xn3Hu2vS9o6MJxID6XG/4TzuVsalYHkelnN9eaXplxgW2JjDRI rbppiOW/1BIxBsluQ9Cd17RKUS/YINiv4IzWlUSOMW+cHqow7foZQCxPpBBQzSOA eejWzgzHKE7dbopZQ/k7nWYS6183jYn67VQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to:sender :list-id; s=fm2; t=1523544431; bh=IyP6urMNTwORKvgjWYSwpy8jy4JBI3 8XnD2HYu82emA=; b=mKjfErHs61p4ZjvAb2gGaNOV+8DPKwVUDzWb0D8QcEACJy pxoH2gmYkk9DmxXVjKkSyQ2Dw8SWIqV5KCNqkVOMcbMRlB+zORwPJILv7npoYOYG 8/zUoTtXZfj/JVU/TI1tPZHsGSNAXD9BldqxxfNfgwtJbZFfdXPud9nVpeREe1fZ tgufLWttPgrMo8ggEh/9Exn7i+I00wYsXwcoIp1SgbZiQbn52lsh+DzvcPmoSTcJ fyARAgYF4WVHS/sYvYcG9//J7A4qSCw9VGNcXSLIzWfzcs7slw3ioYWooHSHao9k 6rvrJYcluLLE4tB8VK1XP0FWMW72pKAG733vQqQw== ARC-Authentication-Results: i=1; mx4.messagingengine.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=none (p=none,has-list-id=yes,d=none) header.from=kernel.org; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=linux-api-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=orgdomain_pass (Domain org match); x-cm=none score=0; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=kernel.org header.result=pass header_is_org_domain=yes; x-vs=clean score=-100 state=0 Authentication-Results: mx4.messagingengine.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=none (p=none,has-list-id=yes,d=none) header.from=kernel.org; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=linux-api-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=orgdomain_pass (Domain org match); x-cm=none score=0; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=kernel.org header.result=pass header_is_org_domain=yes; x-vs=clean score=-100 state=0 X-ME-VSCategory: clean X-CM-Envelope: MS4wfNJfISrIWxs6UL2J9unl/XvUK8TudT6nvhIqD0Vhtd+DMRMHnnaUpmvM/VK3k2N+WjI7jj5c4m0KcHSabgYPWno6YenZdyTK4D0lsdChQllVqqCqwIWH EKHXXZRykXpzQuXTUnEiSHGZMRmMxMdQcwbrD/1D/RMYLX/ub8jm5Xh4r6Qiqqz9ILRNPo+3HGMnNGUDpf8nsUteQf66e45pXpCmErVHMjGOa8ryGqIl7i1n X-CM-Analysis: v=2.3 cv=JLoVTfCb c=1 sm=1 tr=0 a=UK1r566ZdBxH71SXbqIOeA==:117 a=UK1r566ZdBxH71SXbqIOeA==:17 a=kj9zAlcOel0A:10 a=Kd1tUaAdevIA:10 a=VwQbUJbxAAAA:8 a=XeUBy_Da3uTAN91KrT4A:9 a=CjuIK1q_8ugA:10 a=x8gzFH9gYPwA:10 a=AjGcO6oz07-iQ99wixmX:22 X-ME-CMScore: 0 X-ME-CMCategory: none Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752775AbeDLOq4 (ORCPT ); Thu, 12 Apr 2018 10:46:56 -0400 Received: from mx2.suse.de ([195.135.220.15]:45667 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752355AbeDLOqz (ORCPT ); Thu, 12 Apr 2018 10:46:55 -0400 Date: Thu, 12 Apr 2018 16:46:51 +0200 From: Michal Hocko To: Roman Gushchin Cc: Vlastimil Babka , linux-mm@kvack.org, Andrew Morton , Alexander Viro , Johannes Weiner , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, Linux API Subject: Re: [PATCH 1/3] mm: introduce NR_INDIRECTLY_RECLAIMABLE_BYTES Message-ID: <20180412144651.GI23400@dhcp22.suse.cz> References: <20180305133743.12746-1-guro@fb.com> <20180305133743.12746-2-guro@fb.com> <08524819-14ef-81d0-fa90-d7af13c6b9d5@suse.cz> <20180411135624.GA24260@castle.DHCP.thefacebook.com> <46dbe2a5-e65f-8b72-f835-0210bc445e52@suse.cz> <20180412115217.GC23400@dhcp22.suse.cz> <20180412143826.GA30714@castle.DHCP.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180412143826.GA30714@castle.DHCP.thefacebook.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-api-owner@vger.kernel.org X-Mailing-List: linux-api@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Thu 12-04-18 15:38:33, Roman Gushchin wrote: > On Thu, Apr 12, 2018 at 01:52:17PM +0200, Michal Hocko wrote: > > On Thu 12-04-18 08:52:52, Vlastimil Babka wrote: > > > On 04/11/2018 03:56 PM, Roman Gushchin wrote: > > > > On Wed, Apr 11, 2018 at 03:16:08PM +0200, Vlastimil Babka wrote: > > [...] > > > >> With that in mind, can we at least for now put the (manually maintained) > > > >> byte counter in a variable that's not directly exposed via /proc/vmstat, > > > >> and then when printing nr_slab_reclaimable, simply add the value > > > >> (divided by PAGE_SIZE), and when printing nr_slab_unreclaimable, > > > >> subtract the same value. This way we would be simply making the existing > > > >> counters more precise, in line with their semantics. > > > > > > > > Idk, I don't like the idea of adding a counter outside of the vm counters > > > > infrastructure, and I definitely wouldn't touch the exposed > > > > nr_slab_reclaimable and nr_slab_unreclaimable fields. > > > > Why? > > Both nr_slab_reclaimable and nr_slab_unreclaimable have a very simple > meaning: they are numbers of pages used by corresponding slab caches. Right, but if names are reclaimable then they should end up in the reclaimable slabs and to be accounted as such. Objects themselves are not sufficient to reclaim the accounted memory. > In the answer to the very first version of this patchset > Andrew suggested to generalize the idea to allow further > accounting of non-kmalloc() allocations. > I like the idea, even if don't have a good example right now. Well, I have to disagree here. It sounds completely ad-hoc without a reasoable semantic. Or how does it help users when they do not know what is the indirect dependency and how to trigger it. > The problem with external names existed for many years before > we've accidentally hit it, so if we don't have other examples > right now, it doesn't mean that we wouldn't have them in the future. > > > > > > We would be just making the reported values more precise wrt reality. > > > > I was suggesting something similar in an earlier discussion. I am not > > really happy about the new exposed counter either. It is just arbitrary > > by name yet very specific for this particular usecase. > > > > What is a poor user supposed to do with the new counter? Can this be > > used for any calculations? > > For me the most important part is to fix the overcommit logic, because it's > a real security and production issue. Sure, the problem is ugly. Not the first one when the unaccounted kernel allocation can eat a lot of memory. We have many other such. The usual answer was to use kmemcg accounting. -- Michal Hocko SUSE Labs