From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 62960C4361B for ; Mon, 7 Dec 2020 15:02:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id ECBE8236F9 for ; Mon, 7 Dec 2020 15:02:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ECBE8236F9 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4558C8D0002; Mon, 7 Dec 2020 10:02:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 42E9B8D0001; Mon, 7 Dec 2020 10:02:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3422E8D0002; Mon, 7 Dec 2020 10:02:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0217.hostedemail.com [216.40.44.217]) by kanga.kvack.org (Postfix) with ESMTP id 1E7888D0001 for ; Mon, 7 Dec 2020 10:02:58 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id D46538249980 for ; Mon, 7 Dec 2020 15:02:57 +0000 (UTC) X-FDA: 77566803594.10.soap63_3b06f84273df Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id B278716A0DE for ; Mon, 7 Dec 2020 15:02:57 +0000 (UTC) X-HE-Tag: soap63_3b06f84273df X-Filterd-Recvd-Size: 5059 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Mon, 7 Dec 2020 15:02:56 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1607353375; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=W9xHKa0FHxvAY5lMXiXo+4bSevtfetGYjc7M1Qiyftw=; b=FnFflSv8rzalFIyNLjcUy7ngp2i44jvG1FEWcNn7jC3d+hDQcfKh0lVVHNeI/o/sZimsvr eQVcvH5Q2lMWef8fp3aSgRVYGaswMY1kVzgXWO9EkGp22XgMfXXXNYFu5+yGa0hrv2PcsY CmZGpPtTTlzg4iTd4Ch1sfoHjrMfHck= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 8F742ACBD; Mon, 7 Dec 2020 15:02:55 +0000 (UTC) Date: Mon, 7 Dec 2020 16:02:54 +0100 From: Michal Hocko To: Muchun Song Cc: Greg KH , rafael@kernel.org, Alexey Dobriyan , Andrew Morton , Johannes Weiner , Vladimir Davydov , Hugh Dickins , Will Deacon , Roman Gushchin , Mike Rapoport , Thomas Gleixner , esyr@redhat.com, peterx@redhat.com, krisman@collabora.com, Suren Baghdasaryan , avagin@openvz.org, Marco Elver , Randy Dunlap , Joonsoo Kim , LKML , linux-fsdevel , Linux Memory Management List , Cgroups Subject: Re: [External] Re: [RESEND PATCH v2 00/12] Convert all vmstat counters to pages or bytes Message-ID: <20201207150254.GL25569@dhcp22.suse.cz> References: <20201206101451.14706-1-songmuchun@bytedance.com> <20201207130018.GJ25569@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon 07-12-20 22:52:30, Muchun Song wrote: > On Mon, Dec 7, 2020 at 9:00 PM Michal Hocko wrote: > > > > On Sun 06-12-20 18:14:39, Muchun Song wrote: > > > Hi, > > > > > > This patch series is aimed to convert all THP vmstat counters to pages > > > and some KiB vmstat counters to bytes. > > > > > > The unit of some vmstat counters are pages, some are bytes, some are > > > HPAGE_PMD_NR, and some are KiB. When we want to expose these vmstat > > > counters to the userspace, we have to know the unit of the vmstat counters > > > is which one. It makes the code complex. Because there are too many choices, > > > the probability of making a mistake will be greater. > > > > > > For example, the below is some bug fix: > > > - 7de2e9f195b9 ("mm: memcontrol: correct the NR_ANON_THPS counter of hierarchical memcg") > > > - not committed(it is the first commit in this series) ("mm: memcontrol: fix NR_ANON_THPS account") > > > > > > This patch series can make the code simple (161 insertions(+), 187 deletions(-)). > > > And make the unit of the vmstat counters are either pages or bytes. Fewer choices > > > means lower probability of making mistakes :). > > > > > > This was inspired by Johannes and Roman. Thanks to them. > > > > It would be really great if you could summarize the current and after > > the patch state so that exceptions are clear and easier to review. The > > Agree. Will do in the next version. Thanks. > > > > existing situation is rather convoluted but we have at least units part > > of the name so it is not too hard to notice that. Reducing exeptions > > sounds nice but I am not really sure it is such an improvement it is > > worth a lot of code churn. Especially when it comes to KB vs B. Counting > > There are two vmstat counters (NR_KERNEL_STACK_KB and > NR_KERNEL_SCS_KB) whose units are KB. If we do this, all > vmstat counter units are either pages or bytes in the end. When > we expose those counters to userspace, it can be easy. You can > reference to: > > [RESEND PATCH v2 11/12] mm: memcontrol: make the slab calculation consistent > > From this point of view, I think that it is worth doing this. Right? Well, unless I am missing something, we have two counters in bytes, two in kB, both clearly distinguishable by the B/KB suffix. Changing KB to B will certainly reduce the different classes of units, no question about that, but I am not really sure this is worth all the code churn. Maybe others will think otherwise. As I've said the THP accounting change makes more sense to me because it allows future changes which are already undergoing so there is more merit in those. -- Michal Hocko SUSE Labs