Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752233AbdGGQUB (ORCPT <rfc822;w@1wt.eu>);
        Fri, 7 Jul 2017 12:20:01 -0400
Received: from mga14.intel.com ([192.55.52.115]:13630 "EHLO mga14.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752044AbdGGQT7 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 7 Jul 2017 12:19:59 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.40,323,1496127600"; 
   d="scan'208";a="105903221"
Subject: Re: [RFC v2 0/5] surface heterogeneous memory performance information
To: Balbir Singh <bsingharora@gmail.com>,
        Ross Zwisler <ross.zwisler@linux.intel.com>,
        linux-kernel@vger.kernel.org
References: <20170706215233.11329-1-ross.zwisler@linux.intel.com>
 <1499408836.23251.3.camel@gmail.com>
Cc: "Anaczkowski, Lukasz" <lukasz.anaczkowski@intel.com>,
        "Box, David E" <david.e.box@intel.com>,
        "Kogut, Jaroslaw" <Jaroslaw.Kogut@intel.com>,
        "Lahtinen, Joonas" <joonas.lahtinen@intel.com>,
        "Moore, Robert" <robert.moore@intel.com>,
        "Nachimuthu, Murugasamy" <murugasamy.nachimuthu@intel.com>,
        "Odzioba, Lukasz" <lukasz.odzioba@intel.com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
        "Rafael J. Wysocki" <rjw@rjwysocki.net>,
        "Schmauss, Erik" <erik.schmauss@intel.com>,
        "Verma, Vishal L" <vishal.l.verma@intel.com>,
        "Zheng, Lv" <lv.zheng@intel.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Dan Williams <dan.j.williams@intel.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jerome Glisse <jglisse@redhat.com>, Len Brown <lenb@kernel.org>,
        Tim Chen <tim.c.chen@linux.intel.com>, devel@acpica.org,
        linux-acpi@vger.kernel.org, linux-mm@kvack.org,
        linux-nvdimm@lists.01.org
From: Dave Hansen <dave.hansen@intel.com>
Message-ID: <599ebf96-fc06-1478-b805-349d13a0e652@intel.com>
Date: Fri, 7 Jul 2017 09:19:49 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <1499408836.23251.3.camel@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1363
Lines: 36

On 07/06/2017 11:27 PM, Balbir Singh wrote:
> On Thu, 2017-07-06 at 15:52 -0600, Ross Zwisler wrote:
>>   # grep . mem_tgt2/* mem_tgt2/local_init/* 2>/dev/null
>>   mem_tgt2/firmware_id:1

This is here for folks that know their platform and know exactly the
firmware ID (PXM in ACPI parlance) of a given piece of memory.  Without
this, we might be stuck with requiring the NUMA node ID that the kernel
uses to be bound 1:1 with the firmware ID.

>>   mem_tgt2/is_cached:0

This tells whether the memory is cached by some other memory.  MCDRAM is
an example of this.  It can be used as a high-bandwidth cache in front
of the lower-bandwidth DRAM.

This is referred to as "Memory Side Cache Information Structure" in the
ACPI spec: www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf

>>   mem_tgt2/is_enabled:1
>>   mem_tgt2/is_isolated:0

This one is described in detail in the ACPI spec.  It's called
"Reservation hint" in there.

>>   mem_tgt2/phys_addr_base:0x0
>>   mem_tgt2/phys_length_bytes:0x800000000
>>   mem_tgt2/local_init/read_bw_MBps:30720
>>   mem_tgt2/local_init/read_lat_nsec:100
>>   mem_tgt2/local_init/write_bw_MBps:30720
>>   mem_tgt2/local_init/write_lat_nsec:100
> 
> How to these numbers compare to normal system memory?

They're made up in this instance.  But, it's safe to expect 10x swings
in bandwidth in latency, both up and down.