From patchwork Thu Jun 15 02:00:25 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Leizhen (ThunderTown)" X-Patchwork-Id: 9787815 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id E95DA60231 for ; Thu, 15 Jun 2017 02:02:23 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DA77028620 for ; Thu, 15 Jun 2017 02:02:23 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id CF21028625; Thu, 15 Jun 2017 02:02:23 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 46CE628620 for ; Thu, 15 Jun 2017 02:02:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=lBQsabUb33IcPBqv6snB2BNBWqymJkklUWGYyz/uItE=; b=YBnSljauv/N1bx vDgOdgUXE1qO5VDyIV8XO+0fTF5wsNuSXt11MhJjV9I4leSfQQM5pMg+SHukog3V4iH/JTs7R9NIO vbpQjs9y98Ih1J62VC2mnj+Lp6GGRa64+mocaLGUmi7VeCKZyTOSuZ82Kn8YzUoex5Gqc2jApctX2 KeIBXcTvF+324YPBhrNllNGhpce3/UvoV78u8H4ob4h47xozN5zcaIUMCqq7p9UJXRAgluCEEid4v L1Bqh5QUE+VP4fTew11phU4zW7CU18nEY6zI/qwVDt4qQoWInEzSZ/QaCVF3axwcm9m9xL8DmoFcF 2bKXJl6h2VVfp/lNX1Dg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1dLK72-0003dj-DB; Thu, 15 Jun 2017 02:02:20 +0000 Received: from szxga02-in.huawei.com ([45.249.212.188]) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1dLK6y-0003cK-8l for linux-arm-kernel@lists.infradead.org; Thu, 15 Jun 2017 02:02:18 +0000 Received: from 172.30.72.53 (EHLO DGGEML401-HUB.china.huawei.com) ([172.30.72.53]) by dggrg02-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id APJ15638; Thu, 15 Jun 2017 10:00:32 +0800 (CST) Received: from [127.0.0.1] (10.177.23.164) by DGGEML401-HUB.china.huawei.com (10.3.17.32) with Microsoft SMTP Server id 14.3.301.0; Thu, 15 Jun 2017 10:00:21 +0800 Subject: Re: [Question or BUG] [NUMA]: I feel puzzled at the function cpumask_of_node To: Michal Hocko References: <5937C608.7010905@huawei.com> <20170608141214.GJ19866@dhcp22.suse.cz> From: "Leizhen (ThunderTown)" Message-ID: <5941EA39.8090501@huawei.com> Date: Thu, 15 Jun 2017 10:00:25 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20170608141214.GJ19866@dhcp22.suse.cz> X-Originating-IP: [10.177.23.164] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5941EA40.01A2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2846f3b0ff33d00436c54ad0f66a1dba X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20170614_190217_120465_276F56F2 X-CRM114-Status: GOOD ( 10.30 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Catalin Marinas , x86l , Will Deacon , linux-kernel , linux-mm , Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner , linux-api@vger.kernel.org, chenchunxiao , linux-arm-kernel Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP On 2017/6/8 22:12, Michal Hocko wrote: > [CC linux-api] > > On Wed 07-06-17 17:23:20, Leizhen (ThunderTown) wrote: >> When I executed numactl -H(print cpumask_of_node for each node), I got >> different result on X86 and ARM64. For each numa node, the former >> only displayed online CPUs, and the latter displayed all possible >> CPUs. Actually, all other ARCHs is the same to ARM64. >> >> So, my question is: Which case(online or possible) should function >> cpumask_of_node be? Or there is no matter about it? > > Unfortunatelly the documentation is quite unclear > What: /sys/devices/system/node/nodeX/cpumap > Date: October 2002 > Contact: Linux Memory Management list > Description: > The node's cpumap. > > not really helpeful, is it? Semantically I _think_ printing online cpus > makes more sense because it doesn't really make much sense to bind > anything on offline nodes. Generic implementtion of cpumask_of_node > indeed provides only online cpus. I haven't checked specific > implementations of arch specific code but listing offline cpus sounds > confusing to me. > OK, thank you very much. So, how about we directly add "cpumask_and with cpu_online_mask", as below: diff --git a/drivers/base/node.c b/drivers/base/node.c index b10479c..199723d 100644 --- a/drivers/base/node.c +++ b/drivers/base/node.c @@ -28,12 +28,14 @@ static struct bus_type node_subsys = { static ssize_t node_read_cpumap(struct device *dev, bool list, char *buf) { struct node *node_dev = to_node(dev); - const struct cpumask *mask = cpumask_of_node(node_dev->dev.id); + struct cpumask mask; + + cpumask_and(&mask, cpumask_of_node(node_dev->dev.id), cpu_online_mask); /* 2008/04/07: buf currently PAGE_SIZE, need 9 chars per 32 bits. */ BUILD_BUG_ON((NR_CPUS/32 * 9) > (PAGE_SIZE-1)); - return cpumap_print_to_pagebuf(list, buf, mask); + return cpumap_print_to_pagebuf(list, buf, &mask); } static inline ssize_t node_read_cpumask(struct device *dev,