From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 84D462218E92B for ; Fri, 22 Dec 2017 21:10:07 -0800 (PST) Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBN5EDdY091742 for ; Sat, 23 Dec 2017 00:14:57 -0500 Received: from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110]) by mx0a-001b2d01.pphosted.com with ESMTP id 2f19yntadg-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Sat, 23 Dec 2017 00:14:57 -0500 Received: from localhost by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sat, 23 Dec 2017 05:14:54 -0000 Subject: Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT References: <20171214021019.13579-1-ross.zwisler@linux.intel.com> <2d6420f7-0a95-adfe-7390-a2aea4385ab2@linux.vnet.ibm.com> <5d7df981-69c2-e371-f48d-13c418fff134@intel.com> From: Anshuman Khandual Date: Sat, 23 Dec 2017 10:44:34 +0530 MIME-Version: 1.0 In-Reply-To: <5d7df981-69c2-e371-f48d-13c418fff134@intel.com> Message-Id: <3bffaacf-e927-fb06-4dd0-3821f6f82dad@linux.vnet.ibm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Dave Hansen , Anshuman Khandual , Ross Zwisler , linux-kernel@vger.kernel.org Cc: "Box, David E" , linux-mm@kvack.org, "Zheng, Lv , linux-nvdimm@lists.01.org, Rafael J. Wysocki" , Anaczkowski,, Robert, Lukasz, "Erik , Len Brown" , John Hubbard , Jerome Glisse , devel@acpica.org, Kogut,, "Marcin , Brice Goglin" , "Nachimuthu, Murugasamy , Rafael J. Wysocki" , Koziej,, "Joonas , Andrew Morton , Tim Chen" List-ID: On 12/22/2017 10:43 PM, Dave Hansen wrote: > On 12/21/2017 07:09 PM, Anshuman Khandual wrote: >> I had presented a proposal for NUMA redesign in the Plumbers Conference this >> year where various memory devices with different kind of memory attributes >> can be represented in the kernel and be used explicitly from the user space. >> Here is the link to the proposal if you feel interested. The proposal is >> very intrusive and also I dont have a RFC for it yet for discussion here. > I think that's the best reason to "re-use NUMA" for this: it's _not_ > intrusive. > > Also, from an x86 perspective, these HMAT systems *will* be out there. > Old versions of Linux *will* see different types of memory as separate > NUMA nodes. So, if we are going to do something different, it's going > to be interesting to un-teach those systems about using the NUMA APIs > for this. That ship has sailed. I understand the need to fetch these details from ACPI/DT for applications to target these distinct memory only NUMA nodes. This can be done by parsing from platform specific values from /proc/acpi/ or /proc/device-tree/ interfaces. This can be a short term solution before NUMA redesign can be figured out. But adding generic devices like "hmat" in the /sys/devices/ path which will be locked for good, seems problematic. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anshuman Khandual Subject: Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT Date: Sat, 23 Dec 2017 10:44:34 +0530 Message-ID: <3bffaacf-e927-fb06-4dd0-3821f6f82dad@linux.vnet.ibm.com> References: <20171214021019.13579-1-ross.zwisler@linux.intel.com> <2d6420f7-0a95-adfe-7390-a2aea4385ab2@linux.vnet.ibm.com> <5d7df981-69c2-e371-f48d-13c418fff134@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:39054 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750740AbdLWFO5 (ORCPT ); Sat, 23 Dec 2017 00:14:57 -0500 Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBN5EMXj092200 for ; Sat, 23 Dec 2017 00:14:56 -0500 Received: from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110]) by mx0b-001b2d01.pphosted.com with ESMTP id 2f15r23ryn-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Sat, 23 Dec 2017 00:14:56 -0500 Received: from localhost by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sat, 23 Dec 2017 05:14:54 -0000 In-Reply-To: <5d7df981-69c2-e371-f48d-13c418fff134@intel.com> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Dave Hansen , Anshuman Khandual , Ross Zwisler , linux-kernel@vger.kernel.org Cc: "Anaczkowski, Lukasz" , "Box, David E" , "Kogut, Jaroslaw" , "Koss, Marcin" , "Koziej, Artur" , "Lahtinen, Joonas" , "Moore, Robert" , "Nachimuthu, Murugasamy" , "Odzioba, Lukasz" , "Rafael J. Wysocki" , "Rafael J. Wysocki" , "Schmauss, Erik" , "Verma, Vishal L" , "Zheng, Lv" , Andrew Morton , Balbir Singh , Brice Goglin , Dan On 12/22/2017 10:43 PM, Dave Hansen wrote: > On 12/21/2017 07:09 PM, Anshuman Khandual wrote: >> I had presented a proposal for NUMA redesign in the Plumbers Conference this >> year where various memory devices with different kind of memory attributes >> can be represented in the kernel and be used explicitly from the user space. >> Here is the link to the proposal if you feel interested. The proposal is >> very intrusive and also I dont have a RFC for it yet for discussion here. > I think that's the best reason to "re-use NUMA" for this: it's _not_ > intrusive. > > Also, from an x86 perspective, these HMAT systems *will* be out there. > Old versions of Linux *will* see different types of memory as separate > NUMA nodes. So, if we are going to do something different, it's going > to be interesting to un-teach those systems about using the NUMA APIs > for this. That ship has sailed. I understand the need to fetch these details from ACPI/DT for applications to target these distinct memory only NUMA nodes. This can be done by parsing from platform specific values from /proc/acpi/ or /proc/device-tree/ interfaces. This can be a short term solution before NUMA redesign can be figured out. But adding generic devices like "hmat" in the /sys/devices/ path which will be locked for good, seems problematic. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751156AbdLWFPB (ORCPT ); Sat, 23 Dec 2017 00:15:01 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:41812 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750728AbdLWFO5 (ORCPT ); Sat, 23 Dec 2017 00:14:57 -0500 Subject: Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT To: Dave Hansen , Anshuman Khandual , Ross Zwisler , linux-kernel@vger.kernel.org References: <20171214021019.13579-1-ross.zwisler@linux.intel.com> <2d6420f7-0a95-adfe-7390-a2aea4385ab2@linux.vnet.ibm.com> <5d7df981-69c2-e371-f48d-13c418fff134@intel.com> Cc: "Anaczkowski, Lukasz" , "Box, David E" , "Kogut, Jaroslaw" , "Koss, Marcin" , "Koziej, Artur" , "Lahtinen, Joonas" , "Moore, Robert" , "Nachimuthu, Murugasamy" , "Odzioba, Lukasz" , "Rafael J. Wysocki" , "Rafael J. Wysocki" , "Schmauss, Erik" , "Verma, Vishal L" , "Zheng, Lv" , Andrew Morton , Balbir Singh , Brice Goglin , Dan Williams , Jerome Glisse , John Hubbard , Len Brown , Tim Chen , devel@acpica.org, linux-acpi@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@lists.01.org From: Anshuman Khandual Date: Sat, 23 Dec 2017 10:44:34 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <5d7df981-69c2-e371-f48d-13c418fff134@intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17122305-0016-0000-0000-000005105C4D X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17122305-0017-0000-0000-0000284C90BC Message-Id: <3bffaacf-e927-fb06-4dd0-3821f6f82dad@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-23_02:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712230074 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/22/2017 10:43 PM, Dave Hansen wrote: > On 12/21/2017 07:09 PM, Anshuman Khandual wrote: >> I had presented a proposal for NUMA redesign in the Plumbers Conference this >> year where various memory devices with different kind of memory attributes >> can be represented in the kernel and be used explicitly from the user space. >> Here is the link to the proposal if you feel interested. The proposal is >> very intrusive and also I dont have a RFC for it yet for discussion here. > I think that's the best reason to "re-use NUMA" for this: it's _not_ > intrusive. > > Also, from an x86 perspective, these HMAT systems *will* be out there. > Old versions of Linux *will* see different types of memory as separate > NUMA nodes. So, if we are going to do something different, it's going > to be interesting to un-teach those systems about using the NUMA APIs > for this. That ship has sailed. I understand the need to fetch these details from ACPI/DT for applications to target these distinct memory only NUMA nodes. This can be done by parsing from platform specific values from /proc/acpi/ or /proc/device-tree/ interfaces. This can be a short term solution before NUMA redesign can be figured out. But adding generic devices like "hmat" in the /sys/devices/ path which will be locked for good, seems problematic. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-f200.google.com (mail-qt0-f200.google.com [209.85.216.200]) by kanga.kvack.org (Postfix) with ESMTP id 21A1B6B027C for ; Sat, 23 Dec 2017 00:15:03 -0500 (EST) Received: by mail-qt0-f200.google.com with SMTP id r51so22787209qtj.17 for ; Fri, 22 Dec 2017 21:15:03 -0800 (PST) Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com. [148.163.158.5]) by mx.google.com with ESMTPS id h9si4214601qti.441.2017.12.22.21.14.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Dec 2017 21:14:57 -0800 (PST) Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBN5EJQf048406 for ; Sat, 23 Dec 2017 00:14:56 -0500 Received: from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110]) by mx0a-001b2d01.pphosted.com with ESMTP id 2f1cdsx5ht-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Sat, 23 Dec 2017 00:14:56 -0500 Received: from localhost by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sat, 23 Dec 2017 05:14:54 -0000 Subject: Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT References: <20171214021019.13579-1-ross.zwisler@linux.intel.com> <2d6420f7-0a95-adfe-7390-a2aea4385ab2@linux.vnet.ibm.com> <5d7df981-69c2-e371-f48d-13c418fff134@intel.com> From: Anshuman Khandual Date: Sat, 23 Dec 2017 10:44:34 +0530 MIME-Version: 1.0 In-Reply-To: <5d7df981-69c2-e371-f48d-13c418fff134@intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Message-Id: <3bffaacf-e927-fb06-4dd0-3821f6f82dad@linux.vnet.ibm.com> Sender: owner-linux-mm@kvack.org List-ID: To: Dave Hansen , Anshuman Khandual , Ross Zwisler , linux-kernel@vger.kernel.org Cc: "Anaczkowski, Lukasz" , "Box, David E" , "Kogut, Jaroslaw" , "Koss, Marcin" , "Koziej, Artur" , "Lahtinen, Joonas" , "Moore, Robert" , "Nachimuthu, Murugasamy" , "Odzioba, Lukasz" , "Rafael J. Wysocki" , "Rafael J. Wysocki" , "Schmauss, Erik" , "Verma, Vishal L" , "Zheng, Lv" , Andrew Morton , Balbir Singh , Brice Goglin , Dan Williams , Jerome Glisse , John Hubbard , Len Brown , Tim Chen , devel@acpica.org, linux-acpi@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@lists.01.org On 12/22/2017 10:43 PM, Dave Hansen wrote: > On 12/21/2017 07:09 PM, Anshuman Khandual wrote: >> I had presented a proposal for NUMA redesign in the Plumbers Conference this >> year where various memory devices with different kind of memory attributes >> can be represented in the kernel and be used explicitly from the user space. >> Here is the link to the proposal if you feel interested. The proposal is >> very intrusive and also I dont have a RFC for it yet for discussion here. > I think that's the best reason to "re-use NUMA" for this: it's _not_ > intrusive. > > Also, from an x86 perspective, these HMAT systems *will* be out there. > Old versions of Linux *will* see different types of memory as separate > NUMA nodes. So, if we are going to do something different, it's going > to be interesting to un-teach those systems about using the NUMA APIs > for this. That ship has sailed. I understand the need to fetch these details from ACPI/DT for applications to target these distinct memory only NUMA nodes. This can be done by parsing from platform specific values from /proc/acpi/ or /proc/device-tree/ interfaces. This can be a short term solution before NUMA redesign can be figured out. But adding generic devices like "hmat" in the /sys/devices/ path which will be locked for good, seems problematic. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org