Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1930970imu; Wed, 12 Dec 2018 06:49:34 -0800 (PST) X-Google-Smtp-Source: AFSGD/UjCFWStqO3LBniaFkJMjRM6TyDqxddA6YIg6qp6B+R+1idtnMrzapig0Pt7OjesTgMYz1J X-Received: by 2002:a17:902:f01:: with SMTP id 1mr19418165ply.143.1544626174380; Wed, 12 Dec 2018 06:49:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544626174; cv=none; d=google.com; s=arc-20160816; b=NKmVdS4CDW81gK8K3wFz7ZciJUASpFrgto8mOoK41uwpAI33Q4jldaq2dcI0FSE4dx JU1H1LPFCX9+RlKitPwtOYZH5QO9mkY7rzUD7mg78EARVlQt9lhZL4+E5ZQv6p/K8vSy VukrQO9yjrxnwJNas4cVUpP61w5yhLe7rhXVwk2SZvvS4JKFMjs3jykpoOIIPDp7NjDB 3UD4VZSsyABx+NQgorPkcJq5PN05ujUmWHQtY4iMkCJOOTyGPEJtTRrIJE4V0eGLdcJM iKTr2NV61lhNrav00glOJjVsN1vrSLPIphWnm+Povfq2EXomHSu3AOZCPWPi3CJwLMfT gPmw== 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=oSjpBamP3e4tsN9Tz0NeLM7unY/wTZFl2igQo/p0FPI=; b=r3wnn5cNL9zqgAI3LLTBJy/EIVDfavfzGCW23C39bokgAx7kXppV53cgAmX5l3tgXC lnXOLZ7DonTx+roj3DJa7BIAoagIUsiDL4eXEYX7vWR2plu28zwSH91Z0X65lqDE9KbO eWlA8wP7l7lXR0Tw8qpS7skEQvq838/pQIERD+la25KDM1eTozkbML3Evs5fMCF9XgSI Jytc4O17TSkvDQeSYw7vBlYTVvcxQAaqQCyUIkmNYS2v0f2AiFrKiydjbndAbiPS6RDN 4lsdr9+iHJXOYqRaXWm6D8S/JiWn34hZZ7DtpUe3b1RWFWCMJhm2Z+qmEu8bcx+FWPv6 ziuA== 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 bf4si14700713plb.163.2018.12.12.06.49.18; Wed, 12 Dec 2018 06:49:34 -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 S1727313AbeLLOsX (ORCPT + 99 others); Wed, 12 Dec 2018 09:48:23 -0500 Received: from mga18.intel.com ([134.134.136.126]:22652 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726223AbeLLOsW (ORCPT ); Wed, 12 Dec 2018 09:48:22 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2018 06:48:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,344,1539673200"; d="scan'208";a="117766522" Received: from unknown (HELO localhost.localdomain) ([10.232.112.69]) by orsmga002.jf.intel.com with ESMTP; 12 Dec 2018 06:48:21 -0800 Date: Wed, 12 Dec 2018 07:45:53 -0700 From: Keith Busch To: "Aneesh Kumar K.V" 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: [PATCHv2 12/12] doc/mm: New documentation for memory performance Message-ID: <20181212144553.GB10780@localhost.localdomain> References: <20181211010310.8551-1-keith.busch@intel.com> <20181211010310.8551-13-keith.busch@intel.com> <681f14eb-def4-bf40-fdfd-b5fb89045132@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <681f14eb-def4-bf40-fdfd-b5fb89045132@linux.ibm.com> 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 Wed, Dec 12, 2018 at 10:23:24AM +0530, Aneesh Kumar K.V wrote: > On 12/11/18 6:33 AM, Keith Busch wrote: > > +When multiple memory initiators exist, they may not all have the same > > +performance when accessing a given memory target. The highest performing > > +initiator to a given target is considered to be one of that target's > > +local initiators. Any given target may have one or more local initiators, > > +and any given initiator may have multiple local memory targets. > > + > > Can you also add summary here suggesting node X is compute and Node y is > memory target Sure thing. > > +To aid applications matching memory targets with their initiators, > > +the kernel provide symlinks to each other like the following example:: > > + > > + # ls -l /sys/devices/system/node/nodeX/local_target* > > + /sys/devices/system/node/nodeX/local_targetY -> ../nodeY > > + > > + # ls -l /sys/devices/system/node/nodeY/local_initiator* > > + /sys/devices/system/node/nodeY/local_initiatorX -> ../nodeX > > + > > the patch series had primary_target and primary_initiator Yeah, I noticed that mistake too. I went through several iterations of naming this, and I think it will yet be named something else in the final revision to accomodate different access levels since it sounds like some people may wish to show more than just the best. > > +When the kernel first registers a memory cache with a node, the kernel > > +will create the following directory:: > > + > > + /sys/devices/system/node/nodeX/side_cache/ > > + > > This is something even the patch commit message didn't explain we create > side_cache directory in memory target nodes or initiator nodes? I assume it > is part of memory target nodes. If so to be consistent can you use nodeY? Right, only memory targets may have memory side caches. Will use more consistent symbols.