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=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 3F415C433F5 for ; Fri, 24 Sep 2021 01:34:48 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F114460EDF for ; Fri, 24 Sep 2021 01:34:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org F114460EDF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.194724.346961 (Exim 4.92) (envelope-from ) id 1mTa6k-0002oC-Ki; Fri, 24 Sep 2021 01:34:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 194724.346961; Fri, 24 Sep 2021 01:34:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mTa6k-0002o5-Hc; Fri, 24 Sep 2021 01:34:34 +0000 Received: by outflank-mailman (input) for mailman id 194724; Fri, 24 Sep 2021 01:34:33 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mTa6j-0002nz-Lp for xen-devel@lists.xenproject.org; Fri, 24 Sep 2021 01:34:33 +0000 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7ba2ad18-6209-4b54-b2ca-c184f914a455; Fri, 24 Sep 2021 01:34:32 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id E0CB561211; Fri, 24 Sep 2021 01:34:31 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7ba2ad18-6209-4b54-b2ca-c184f914a455 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1632447272; bh=FQN+nMr8/U87vCJiePijUNnGt4KoccfGqtNT+UZamTU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=XX6zcmJ1vetRjtZFkj2n/AQNIgB8cvQ7zPougum05LvEvKuZ9vXAo+yy0IDenFUrH BxJzxAq0o2MyxSZnWSQUqOItdDzRvCLFGdG3+6i892+/O2l9ltA8ySGf208Z6ESBNx WmLfGq4qxwDhGUgGQeQMgLVi9hJIKA4fmDSTBQjWRhQhYY6D+IpLBwHrQq5g8v/MvT xzSw6QNJEQ3pXFnkh6OyQ+RUUGp1jn2tiva37bSjZ0Xw2ivGr68ue/4cDTcM/BySLz dPkVTexNoceZI5dbYmNzIHbA8rGRkeZdzcyzNTLaDueMzYxLUaF0v/hz4thg8rH5bw ly/wRmvN+kA4A== Date: Thu, 23 Sep 2021 18:34:30 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Wei Chen cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, julien@xen.org, Bertrand.Marquis@arm.com Subject: Re: [PATCH 22/37] xen/arm: use NR_MEM_BANKS to override default NR_NODE_MEMBLKS In-Reply-To: <20210923120236.3692135-23-wei.chen@arm.com> Message-ID: References: <20210923120236.3692135-1-wei.chen@arm.com> <20210923120236.3692135-23-wei.chen@arm.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Thu, 23 Sep 2021, Wei Chen wrote: > As a memory range described in device tree cannot be split across > multiple nodes. So we define NR_NODE_MEMBLKS as NR_MEM_BANKS in > arch header. This statement is true but what is the goal of this patch? Is it to reduce code size and memory consumption? I am asking because NR_MEM_BANKS is 128 and NR_NODE_MEMBLKS=2*MAX_NUMNODES which is 64 by default so again NR_NODE_MEMBLKS is 128 before this patch. In other words, this patch alone doesn't make any difference; at least doesn't make any difference unless CONFIG_NR_NUMA_NODES is increased. So, is the goal to reduce memory usage when CONFIG_NR_NUMA_NODES is higher than 64? > And keep default NR_NODE_MEMBLKS in common header > for those architectures NUMA is disabled. This last sentence is not accurate: on x86 NUMA is enabled and NR_NODE_MEMBLKS is still defined in xen/include/xen/numa.h (there is no x86 definition of it) > Signed-off-by: Wei Chen > --- > xen/include/asm-arm/numa.h | 8 +++++++- > xen/include/xen/numa.h | 2 ++ > 2 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h > index 8f1c67e3eb..21569e634b 100644 > --- a/xen/include/asm-arm/numa.h > +++ b/xen/include/asm-arm/numa.h > @@ -3,9 +3,15 @@ > > #include > > +#include > + > typedef u8 nodeid_t; > > -#ifndef CONFIG_NUMA > +#ifdef CONFIG_NUMA > + > +#define NR_NODE_MEMBLKS NR_MEM_BANKS > + > +#else > > /* Fake one node for now. See also node_online_map. */ > #define cpu_to_node(cpu) 0 > diff --git a/xen/include/xen/numa.h b/xen/include/xen/numa.h > index 1978e2be1b..1731e1cc6b 100644 > --- a/xen/include/xen/numa.h > +++ b/xen/include/xen/numa.h > @@ -12,7 +12,9 @@ > #define MAX_NUMNODES 1 > #endif > > +#ifndef NR_NODE_MEMBLKS > #define NR_NODE_MEMBLKS (MAX_NUMNODES*2) > +#endif > > #define vcpu_to_node(v) (cpu_to_node((v)->processor)) > > -- > 2.25.1 >