Received: by 10.192.165.156 with SMTP id m28csp1859933imm; Thu, 12 Apr 2018 04:55:51 -0700 (PDT) X-Google-Smtp-Source: AIpwx4816RyPFRet5L70oWdLhwxuXh3xoxzbgD5O2qGdcdNYbNiMmaIzll6MznkHTkU1a4hsmrDY X-Received: by 10.101.77.67 with SMTP id j3mr492103pgt.210.1523534151638; Thu, 12 Apr 2018 04:55:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523534151; cv=none; d=google.com; s=arc-20160816; b=opETE0Gd/ddgnjTsBclRXFKbm1FSFMT63Yq12YpzRTKU1XIAlRPeTjVpvdNBO4kJvP i08bQ7g6QbqCuALybS1U9nR61X+p+POIwp/QnhdcAVFW43+F0ZxHZUCNaxpB+SbESybO RkqaF60A/tiqDwA4jCAl6a/IsDgN7L4/0yQm6Wr0VxqkWUcvZUG2N9V14a0UJs+TC2D1 CZU1ekb3dJAEW/h8Hb5nyS7AIEayAWpoTkQkaiv/V4ePdhwOMxV8lCYhBdLcxwWi9KrK csGh4fmSA25pFJ9y1rvOCiDYB7Cga9sA5IuxAwVb6M+aifc7GV+R07R+I2JvUKQM2gUK jwyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=C98GDx0y8OoBl3A6fbrs9ZnZoPk+WsIEhpjNdslIFRg=; b=S8oHIFf9g7Zh0bZpSepqToitCZKxetJPH6Ecwo8dcvafDBPAtKyH1PvNaw+E5EMcXZ 0/svrP3IwxqC6ekG6v1lsl1oIhmbedS7tuYN+70+l6g3oyBd4Al5+gG36Pn73Ab71r9V ufn8hWkb+ze9+RczETvtyFPBMZ4pV6BOziYhcIed8oyLy14ESoxTaNAMX5hR4senp1t7 hAvGEQEe7KBIz+c6BzSuUorHKhTVDJlqaT9NfKqu3B0uXFQdS/y+soMXzDV0hCrDsllS T5YbwjOH4f6YQNym+S33FXVqEGgFJAnzFnFMVkcNIh73Y9Qiqh8kbVGi5vR+PzUQQRBG xfyQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a32-v6si3193177pla.313.2018.04.12.04.55.14; Thu, 12 Apr 2018 04:55:51 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752829AbeDLLwZ (ORCPT + 99 others); Thu, 12 Apr 2018 07:52:25 -0400 Received: from mx2.suse.de ([195.135.220.15]:49376 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751889AbeDLLwW (ORCPT ); Thu, 12 Apr 2018 07:52:22 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id CA2EDAC81; Thu, 12 Apr 2018 11:52:19 +0000 (UTC) Date: Thu, 12 Apr 2018 13:52:17 +0200 From: Michal Hocko To: Vlastimil Babka Cc: Roman Gushchin , 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: <20180412115217.GC23400@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46dbe2a5-e65f-8b72-f835-0210bc445e52@suse.cz> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? > 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? -- Michal Hocko SUSE Lab