From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751037AbdL3JTh (ORCPT ); Sat, 30 Dec 2017 04:19:37 -0500 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:37091 "EHLO mail3-relais-sop.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750888AbdL3JTd (ORCPT ); Sat, 30 Dec 2017 04:19:33 -0500 X-IronPort-AV: E=Sophos;i="5.45,478,1508796000"; d="scan'208";a="249722660" Subject: Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT To: Matthew Wilcox Cc: Dan Williams , Ross Zwisler , Dave Hansen , Michal Hocko , "linux-kernel@vger.kernel.org" , "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 , Jerome Glisse , John Hubbard , Len Brown , Tim Chen , devel@acpica.org, Linux ACPI , Linux MM , "linux-nvdimm@lists.01.org" , Linux API , linuxppc-dev References: <20171218203547.GA2366@linux.intel.com> <20171220181937.GB12236@bombadil.infradead.org> <2da89d31-27a3-34ab-2dbb-92403c8215ec@intel.com> <20171220211649.GA32200@bombadil.infradead.org> <20171220212408.GA8308@linux.intel.com> <20171220224105.GA27258@linux.intel.com> <39cbe02a-d309-443d-54c9-678a0799342d@gmail.com> <71317994-af66-a1b2-4c7a-86a03253cf62@gmail.com> <20171230065845.GD27959@bombadil.infradead.org> From: Brice Goglin Message-ID: <74a585de-c825-b568-ee14-c8799b9d6238@gmail.com> Date: Sat, 30 Dec 2017 10:19:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171230065845.GD27959@bombadil.infradead.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 30/12/2017 à 07:58, Matthew Wilcox a écrit : > On Wed, Dec 27, 2017 at 10:10:34AM +0100, Brice Goglin wrote: >>> Perhaps we can enlist /proc/iomem or a similar enumeration interface >>> to tell userspace the NUMA node and whether the kernel thinks it has >>> better or worse performance characteristics relative to base >>> system-RAM, i.e. new IORES_DESC_* values. I'm worried that if we start >>> publishing absolute numbers in sysfs userspace will default to looking >>> for specific magic numbers in sysfs vs asking the kernel for memory >>> that has performance characteristics relative to base "System RAM". In >>> other words the absolute performance information that the HMAT >>> publishes is useful to the kernel, but it's not clear that userspace >>> needs that vs a relative indicator for making NUMA node preference >>> decisions. >> Some HPC users will benchmark the machine to discovery actual >> performance numbers anyway. >> However, most users won't do this. They will want to know relative >> performance of different nodes. If you normalize HMAT values by dividing >> them with system-RAM values, that's likely OK. If you just say "that >> node is faster than system RAM", it's not precise enough. > So "this memory has 800% bandwidth of normal" and "this memory has 70% > bandwidth of normal"? I guess that would work. Brice