Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp3636666ybg; Fri, 25 Oct 2019 06:56:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqyZi6g3GhIyrt49OPQ+xTnFWV47YxoptHcfwszTiguKFyGgULnB8pzkT8Oeg02TuH5F58YW X-Received: by 2002:a50:a227:: with SMTP id 36mr4015041edl.262.1572011817158; Fri, 25 Oct 2019 06:56:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572011817; cv=none; d=google.com; s=arc-20160816; b=CmRgkNr+2iloib/Zb94XM5iNwEHbCoQQaK3weONDo8vNg5agcBBeiVkBh6v3q9c3lU /HQzn3XhIUsZmfRFHtIc14JygjTjQ+jfu0UlCiy2sx+RxRybs3lxBl9nlZbNm0b1+Ft3 YXFrsTBvUzhq7ccqb3jtps9GjM0xr85QCVTx0bOlPjx1Qr6FqnBKqahwxg0rs/kFa3mc P/NsnQrwq67wu7QP0kZxIViaV8qPWD2xD8KuxImJ/n5LC9my/tFlpYg1XGRpN/DKtVk9 a63OVTRTU/aDouJklgRrlukHbBnBkOYV0e6cYYIbCgeAyQMtRuS4rIlmXXeapmdCrSg0 IgGg== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=DIAD7dBP8eDi12iM9f2yfZekSQt4O1K44yuJL9anV/s=; b=iJBw1UjjjNBLlkf/a3PqIU5kfTms+p55DkgPiJ27r1WrHCrfqe5SFHk4Bh+YXK7XeI EPLVR91s/htykwrH3Pv4YLrWGfUT43sHglqJ5lJFg/qGQ4CUmZm5TvxPx+dka+k1SIuB 2DYP5f3QqKZi1ZLz90QTgTGSA8MtyCQx6F5l4g1S+vVPC1zJJr9zEDN1JqjlVdmEuheM 6ZAE0dfsQVZm66EHNGyV+ugdvBQbKldV4xcTgs+d1KLLm4J+rNXwTxd2ub/cfwDaMnzR auTdZqK5xJKL0UYqCaE9+VOW2Pkg+Sdy0V8JXl1xCOzwhmECkv422co6TGsVR1386pvL zKxw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ay27si1249014edb.216.2019.10.25.06.56.33; Fri, 25 Oct 2019 06:56:57 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2393629AbfJXNjE (ORCPT + 99 others); Thu, 24 Oct 2019 09:39:04 -0400 Received: from mx2.suse.de ([195.135.220.15]:46778 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1733296AbfJXNjD (ORCPT ); Thu, 24 Oct 2019 09:39:03 -0400 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 D4BAABD14; Thu, 24 Oct 2019 13:39:01 +0000 (UTC) Date: Thu, 24 Oct 2019 15:38:59 +0200 From: Michal Hocko To: Qian Cai Cc: Andrew Morton , Waiman Long , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Johannes Weiner , Roman Gushchin , Vlastimil Babka , Konstantin Khlebnikov , Jann Horn , Song Liu , Greg Kroah-Hartman , Rafael Aquini Subject: Re: [PATCH] mm/vmstat: Reduce zone lock hold time when reading /proc/pagetypeinfo Message-ID: <20191024133859.GX17610@dhcp22.suse.cz> References: <20191024074205.GQ17610@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 24-10-19 07:11:52, Qian Cai wrote: > > > > On Oct 24, 2019, at 3:42 AM, Michal Hocko wrote: > > > > It's been useful for debugging memory fragmentation problems and we do > > not have anything that would provide a similar information. Considering > > Actually, zoneinfo and buddyinfo are somewhat similar to it. Why > the extra information in pagetypeinfo is still useful in debugging > today’s real-world scenarios? Because the migrate type is the information that helps to understand fragmentation related issues. I am pretty sure Vlastimil would tell you much more. > > that making it root only is trivial and reducing the lock hold times > > likewise I do not really see any strong reason to dump it at this > > moment. > > There is no need to hurry this, and clearly this is rather a good > opportunity to discuss the consolidation of memory fragmentation > debugging to ease the maintenance in long term. Right. I think we should address the issue at hands first and then handle any possible consolidations. -- Michal Hocko SUSE Labs