Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp8129979imu; Thu, 15 Nov 2018 07:04:55 -0800 (PST) X-Google-Smtp-Source: AJdET5d9n2U/QBhCOnc3FPrgpp06uBra/A3KM3v6kiFrhwSeu1ARar6RvsjZGo020M6+P5mdYFkJ X-Received: by 2002:a63:fe48:: with SMTP id x8mr6227926pgj.261.1542294295887; Thu, 15 Nov 2018 07:04:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542294295; cv=none; d=google.com; s=arc-20160816; b=Mw6SbZnOuVW2YQ3U9H5gvJftLXEZkv5HJD9kBQc1fc0EWKjDPbEW50j9Iwp2L/k5AA OrKrhFZsWEks7wbsUYeoh5xWI0imNg804W+vHZF3Vj1zmKn9khAp0AFjZkFcL9L7pJNx wrgWipvZVOd2RQHOpIaqlksFf5Zit4cfN1+jCp6CQvSsYvbeOCNRhhyY70HSd0PJSwFT uh1d2/hxz79N0ZRT0NTG6o8Dw590KK37TPrn4AnuM/ccuaH4CXNj5FUwkoSAb92UJXqJ EdHoxPkDr6QaEWQcFmzjDPxCuCZQp7Plxk9vWC+vHIodSZlZL5M5grpPXShQpEJhlVIP X24g== 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=O+0RB7GEJe/WYhGuwZxOsatIIBQVTkq3Uz1BNRlZk+Y=; b=EY+OvtiIvqkWkiBxuxFBX1h2xq9+UOwIuWf3q8FUQbp7Kh2PE37kd0BF/VnDKnN+IP MbkFr0TU1mxgVdX4lsmIRPzX7KsHrfpTS221P68ye/oo4au6FcVihIqW0xYM+62Ee5I6 uApmQbBzOMsCvntHTG3tJroa/KlyAR1Ia2Z+4FmOhh6A5HLmELVLbJlB9Kb0fMTJgpCY PXL/uN/maZwM8thHraOFvfCD0z9iIEYipqsEfrLYCGHoWshbpZzDJiOMiNCCptgJyfIF oTlRbsPcbyHzzZmNT9CpaNBqYbsb8io0jfg+IUCpqZr1XIguYQag8CsN69FOCy+Q96Vn 8u7w== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u1-v6si22559808pfb.4.2018.11.15.07.04.32; Thu, 15 Nov 2018 07:04:55 -0800 (PST) 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388454AbeKPBK5 (ORCPT + 99 others); Thu, 15 Nov 2018 20:10:57 -0500 Received: from mga09.intel.com ([134.134.136.24]:2786 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726185AbeKPBK5 (ORCPT ); Thu, 15 Nov 2018 20:10:57 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2018 07:02:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,236,1539673200"; d="scan'208";a="281348564" Received: from unknown (HELO localhost.localdomain) ([10.232.112.69]) by fmsmga006.fm.intel.com with ESMTP; 15 Nov 2018 07:02:45 -0800 Date: Thu, 15 Nov 2018 07:59:20 -0700 From: Keith Busch To: Matthew Wilcox Cc: linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-mm@kvack.org, Greg Kroah-Hartman , Rafael Wysocki , Dave Hansen , Dan Williams Subject: Re: [PATCH 1/7] node: Link memory nodes to their compute nodes Message-ID: <20181115145920.GG11416@localhost.localdomain> References: <20181114224921.12123-2-keith.busch@intel.com> <20181115135710.GD19286@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181115135710.GD19286@bombadil.infradead.org> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 15, 2018 at 05:57:10AM -0800, Matthew Wilcox wrote: > On Wed, Nov 14, 2018 at 03:49:14PM -0700, Keith Busch wrote: > > Memory-only nodes will often have affinity to a compute node, and > > platforms have ways to express that locality relationship. > > > > A node containing CPUs or other DMA devices that can initiate memory > > access are referred to as "memory iniators". A "memory target" is a > > node that provides at least one phyiscal address range accessible to a > > memory initiator. > > I think I may be confused here. If there is _no_ link from node X to > node Y, does that mean that node X's CPUs cannot access the memory on > node Y? In my mind, all nodes can access all memory in the system, > just not with uniform bandwidth/latency. The link is just about which nodes are "local". It's like how nodes have a cpulist. Other CPUs not in the node's list can acces that node's memory, but the ones in the mask are local, and provide useful optimization hints. Would a node mask would be prefered to symlinks?