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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 D5B7CCA9EBD for ; Fri, 25 Oct 2019 12:00:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9C0FA21872 for ; Fri, 25 Oct 2019 12:00:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9C0FA21872 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4A3646B0006; Fri, 25 Oct 2019 08:00:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 47AB26B0007; Fri, 25 Oct 2019 08:00:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 36A406B0008; Fri, 25 Oct 2019 08:00:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0155.hostedemail.com [216.40.44.155]) by kanga.kvack.org (Postfix) with ESMTP id 156646B0006 for ; Fri, 25 Oct 2019 08:00:29 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id A330468B9 for ; Fri, 25 Oct 2019 12:00:28 +0000 (UTC) X-FDA: 76082164536.06.linen17_78844e8481f03 X-HE-Tag: linen17_78844e8481f03 X-Filterd-Recvd-Size: 2933 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Fri, 25 Oct 2019 12:00:28 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 5C5C6AE09; Fri, 25 Oct 2019 12:00:26 +0000 (UTC) Date: Fri, 25 Oct 2019 13:00:23 +0100 From: Mel Gorman To: Qian Cai Cc: Michal Hocko , Andrew Morton , Waiman Long , Johannes Weiner , Roman Gushchin , Vlastimil Babka , Konstantin Khlebnikov , Jann Horn , Song Liu , Greg Kroah-Hartman , Rafael Aquini , linux-mm@kvack.org, LKML , Michal Hocko Subject: Re: [PATCH 2/2] mm, vmstat: reduce zone->lock holding time by /proc/pagetypeinfo Message-ID: <20191025120023.GD28938@suse.de> References: <192965B3-B446-499C-AEE8-DFF087D46B87@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <192965B3-B446-499C-AEE8-DFF087D46B87@lca.pw> User-Agent: Mutt/1.10.1 (2018-07-13) 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 Fri, Oct 25, 2019 at 07:18:37AM -0400, Qian Cai wrote: > ??? > > > On Oct 25, 2019, at 3:26 AM, Michal Hocko wrote: > > > > Considering the pagetypeinfo is a debugging tool we do not really need > > exact numbers here. The primary reason to look at the outuput is to see > > how pageblocks are spread among different migratetypes and low number of > > pages is much more interesting therefore putting a bound on the number > > of pages on the free_list sounds like a reasonable tradeoff. > > > > The new output will simply tell > > [...] > > Node 6, zone Normal, type Movable >100000 >100000 >100000 >100000 41019 31560 23996 10054 3229 983 648 > > It was mentioned that developers could use this file is to see the movement of those numbers for debugging, so this supposed to introduce regressions as there is no movement anymore for those 100k+ items? They would need to be more explicit on what their requirements are. When the file was first introduced, the main interesting point was to see an approximate distribution of orders by migration type. The exact count was not particularly interesting other than knowing whether there was large numbers at lower orders that could not be recovered by compaction/drop_caches/hugetlbfs-allocation/memhog-abuse etc and the distribution of pageblocks by migration type overall. That was my perspective at least when developing fragmentation avoidance, lumpy reclaim and later compaction. -- Mel Gorman SUSE Labs