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=-1.0 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 49298C43331 for ; Thu, 26 Mar 2020 06:43:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E245A20714 for ; Thu, 26 Mar 2020 06:43:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E245A20714 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 406A26B000A; Thu, 26 Mar 2020 02:43:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3B9166B000C; Thu, 26 Mar 2020 02:43:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A6146B000D; Thu, 26 Mar 2020 02:43:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0092.hostedemail.com [216.40.44.92]) by kanga.kvack.org (Postfix) with ESMTP id 13A1C6B000A for ; Thu, 26 Mar 2020 02:43:43 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id ED3B352CB for ; Thu, 26 Mar 2020 06:43:42 +0000 (UTC) X-FDA: 76636572684.21.way84_34c4b0ed9d62 X-HE-Tag: way84_34c4b0ed9d62 X-Filterd-Recvd-Size: 5416 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by imf23.hostedemail.com (Postfix) with ESMTP for ; Thu, 26 Mar 2020 06:43:42 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id 31so6348111wrs.3 for ; Wed, 25 Mar 2020 23:43:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=zPvE1lnXsSi8Kx3PcPb+s1+Cw8243rYkgn6Gll8JJq8=; b=dTokFYGBcGrQSlRBjZxCF/vQ/893UfVhqEdyeNXhZKBJY5IbzcmczlvGS2rmCU/F1D pC4YVt89Vvg3ourlaLl70FWOhDF5CHgCyDMan+hj9S8SzjiDDz9E77TO63LCfqG9j/td vRoj7AEmCPQeBst0Nj8KT/WVsHefgE8C2IhkCX8a3bcU+rNq+D4HO3Zd394qqQRsfq4s FYc/DI3Ns/a2onD0zCw6MRYB1wtOdaLr6gMVVNFIkdzP39lTgQd8c09V6bYx/ao29YEi 8y0ZOvrtkkIzFdzCR9gAbXubXBDJHbcKhFcVjs8MjMiLIsnyf+dcLCAQYNd5t0sAQvC+ ojPA== X-Gm-Message-State: ANhLgQ1474IneKJa/gXFY063v4TsIsrQDS1gQad/LBD17yp47kkbsm+A po3fA4WwK2CCRyfmv6D3ny0= X-Google-Smtp-Source: ADFU+vv3KAOE5Ki5XlMlbPu6EchekM7Vf0TxjYqamCS2n9m2ZU1ZrM/BLGlbDPBnRmP7qCvjySktRQ== X-Received: by 2002:adf:eb0c:: with SMTP id s12mr7497382wrn.293.1585205021142; Wed, 25 Mar 2020 23:43:41 -0700 (PDT) Received: from localhost (ip-37-188-135-150.eurotel.cz. [37.188.135.150]) by smtp.gmail.com with ESMTPSA id w7sm2129103wrr.60.2020.03.25.23.43.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Mar 2020 23:43:39 -0700 (PDT) Date: Thu, 26 Mar 2020 07:43:39 +0100 From: Michal Hocko To: Baoquan He Cc: David Rientjes , linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, vbabka@suse.cz, mgorman@techsingularity.net Subject: Re: [PATCH 4/5] mm/vmstat.c: move the per-node stats to the front of /proc/zoneinfo Message-ID: <20200326064339.GA27965@dhcp22.suse.cz> References: <20200324142229.12028-1-bhe@redhat.com> <20200324142229.12028-5-bhe@redhat.com> <20200325055331.GB9942@MiWiFi-R3L-srv> <20200325085537.GZ19542@dhcp22.suse.cz> <20200325142315.GC9942@MiWiFi-R3L-srv> <20200326042454.GD9942@MiWiFi-R3L-srv> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200326042454.GD9942@MiWiFi-R3L-srv> 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 Thu 26-03-20 12:24:54, Baoquan He wrote: > On 03/25/20 at 12:45pm, David Rientjes wrote: > > On Wed, 25 Mar 2020, Baoquan He wrote: > > > > > > Even this can break existing parsers. Fixing that up is likely not hard > > > > and existing parsers would be mostly debugging hacks here and there but > > > > I do miss any actual justification except for you considering it more > > > > sensible. I do not remember this would be a common pain point for people > > > > parsing this file. If anything the overal structure of the file makes it > > > > hard to parse and your patches do not really address that. We are likely > > > > too late to make the output much more sensible TBH. > > > > > > > > That being said, I haven't looked more closely on your patches because I > > > > do not have spare cycles for that. Your justification for touching the > > > > code which seems to be working relatively well is quite weak IMHO, yet > > > > it adds a non zero risk for breaking existing parsers. > > > > > > I would take the saying of non zero risk for breaking existing parsers. > > > When considering this change, I thought about the possible risk. However, > > > found out the per-node stats was added in 2016 which is not so late, and > > > assume nobody will rely on the order of per-node stats embeded into a > > > zone. But I have to admit any concern or worry of risk is worth being > > > considerred carefully since /proc/zoneinfo is a classic interface. > > > > > > > For context, we started parsing /proc/zoneinfo in initscripts to be able > > to determine the order in which vm.lowmem_reserve_ratio needs to be set > > and this required my kernel change from 2017: > > > > commit b2bd8598195f1b2a72130592125ac6b4218988a2 > > Author: David Rientjes > > Date: Wed May 3 14:52:59 2017 -0700 > > > > mm, vmstat: print non-populated zones in zoneinfo > > > > Otherwise, we found, it's much more difficult to determine how this array > > should be structured. So at least we parse this file very carefully, I'm > > not sure how much others do, but it seems like an unnecessary risk for > > little reward. I'm happy to see it has been decided to drop this patch > > and patch 5. > > > OK, I see why it is in such a situation, the empty zones were not printed. > > I could still not get how vm.lowmem_reserve_ratio is set with > /proc/zoneinfo in the old initscripts, do you see any risk if not > filling and showing the ->lowmem_reserve[] of empty zone in > patch 2 and 3? Thanks in advance. The point is why should we even care. Displaying that information shouldn't hurt anything, right? -- Michal Hocko SUSE Labs