Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp2077696imc; Tue, 12 Mar 2019 06:40:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqx1UUTn3lIhbXesYhAFe4AVK3yEL+Uo0ohC6RGMN8FufyzcEYu6ljY7Nio3xiZUL82t1iN0 X-Received: by 2002:aa7:924e:: with SMTP id 14mr39155876pfp.30.1552398031152; Tue, 12 Mar 2019 06:40:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552398031; cv=none; d=google.com; s=arc-20160816; b=nPXi7wES+STmLz5KjADL5W0HDLQwMGg86Bh2OYrqC22QBYxKCGupLAih3gDkfIbUYL rPPl10hPukwQjtGoxPHsAwXut2v7Vs98pWAib81GUFqMb1JceaESiGybm5bUf10LcWak VAackCT5GlO1Cvbj9KrmHh93vYOeZQE9uBWpFyr3d3eswOLBylI/UABo2TuRHfu4IuFb YfmfLpa0hK1BHRmuglSL9giXvQTY6bsUEEjSSivrFSP5OCZvG5aanUAuxMfqknCyZUWW NQT78k+xcCPU7sXyc7HT2n6oYndyILd00MuXumtr3YMbI/hX7G3+ZRz2GLY02MYEHaG2 Dpcg== 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; bh=QmDFKBE+xLlrM0c7pAqRwIGfEpJzAy6/UODZOWHAE+E=; b=iQ2t+sTTxrbaLomSdWu8XvAJQic1z8R9MiuBP9vkojrN19ICeosyCgOjxmuHTIGzmG n8SJUWXAoHJRgTk6TtltQXoQB0fwKOX8lDmlfhkwAcnCeFiBBKwNEFFe3sMBMUYVaHV4 TuqLhcjPN9GmWeq2bJeFzQukjU++KvIvzHHSz/Ou1HwTVwB9ot4mJA3gJSTQVelZsZL7 ZPu+7VCkB27QrdjJpMp6BwDsChe/RvgL7Thixw6ItONnCJwcfK234/olkj4zf4PEY22/ ywfxzWea9cV/srMCwAkPEEdk+7M2KN6elTRpDwDRkWZbspdElQynRBAZcEU1X8m5a3ev axig== 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 q9si7463641pgq.173.2019.03.12.06.40.12; Tue, 12 Mar 2019 06:40:31 -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 S1726758AbfCLNiT (ORCPT + 99 others); Tue, 12 Mar 2019 09:38:19 -0400 Received: from mx2.suse.de ([195.135.220.15]:50554 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725774AbfCLNiS (ORCPT ); Tue, 12 Mar 2019 09:38:18 -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 A54D5ABCF; Tue, 12 Mar 2019 13:38:17 +0000 (UTC) Date: Tue, 12 Mar 2019 14:38:16 +0100 From: Michal Hocko To: Yafang Shao Cc: Vlastimil Babka , Souptick Joarder , Andrew Morton , Linux MM , LKML , shaoyafang@didiglobal.com Subject: Re: [PATCH] mm: vmscan: show zone type in kswapd tracepoints Message-ID: <20190312133816.GR5721@dhcp22.suse.cz> References: <1551425934-28068-1-git-send-email-laoar.shao@gmail.com> <20190311084743.GX5232@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 Tue 12-03-19 19:04:43, Yafang Shao wrote: > On Mon, Mar 11, 2019 at 4:47 PM Michal Hocko wrote: > > > > On Fri 01-03-19 15:38:54, Yafang Shao wrote: > > > If we want to know the zone type, we have to check whether > > > CONFIG_ZONE_DMA, CONFIG_ZONE_DMA32 and CONFIG_HIGHMEM are set or not, > > > that's not so convenient. > > > > > > We'd better show the zone type directly. > > > > I do agree that zone number is quite PITA to process in general but do > > we really need this information in the first place? Why do we even care? > > > > Sometimes we want to know this event occurs in which zone, then we can > get the information of this zone, > for example via /proc/zoneinfo. > It could give us more information for debugging. Could you be more specific please? > > Zones are an MM internal implementation details and the more we export > > to the userspace the more we are going to argue about breaking userspace > > when touching them. So I would rather not export that information unless > > it is terribly useful. > > > > I 'm not sure whether zone type is terribly useful or not, but the > 'zid' is useless at all. > > I don't agree that Zones are MM internal. > We can get the zone type in many ways, for example /proc/zoneinfo. > > If we show this event occurs in which zone, we'd better show the zone type, > or we should drop this 'zid'. Yes, I am suggesting the later. If somebody really needs it then I would like to see a _specific_ usecase. Then we can add the proper name. -- Michal Hocko SUSE Labs