From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-x244.google.com (mail-ot0-x244.google.com [IPv6:2607:f8b0:4003:c0f::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5457922085869 for ; Fri, 22 Dec 2017 17:09:52 -0800 (PST) Received: by mail-ot0-x244.google.com with SMTP id v21so26464325oth.6 for ; Fri, 22 Dec 2017 17:14:42 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20171214130032.GK16951@dhcp22.suse.cz> <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> <20171222232231.GA26715@linux.intel.com> From: "Rafael J. Wysocki" Date: Sat, 23 Dec 2017 02:14:41 +0100 Message-ID: Subject: Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Dan Williams Cc: Michal Hocko , "Box, David E" , Dave Hansen , "Zheng, Lv" , "linux-nvdimm@lists.01.org" , "Rafael J. Wysocki" , Anaczkowski,, "Robert , Matthew Wilcox , Linux ACPI" , Odzioba,, "Erik , Len Brown" , John Hubbard , linuxppc-dev , Jerome Glisse , devel@acpica.org, Kogut,, "Marcin , Linux API , Brice Goglin" , "Nachimuthu, Murugasamy , Rafael J. Wysocki" , "linux-kernel@vger.kernel.org" , Koziej,, "Joonas , Andrew Morton , Tim Chen" List-ID: T24gU2F0LCBEZWMgMjMsIDIwMTcgYXQgMTI6NTcgQU0sIERhbiBXaWxsaWFtcyA8ZGFuLmoud2ls bGlhbXNAaW50ZWwuY29tPiB3cm90ZToKPiBPbiBGcmksIERlYyAyMiwgMjAxNyBhdCAzOjIyIFBN LCBSb3NzIFp3aXNsZXIKPiA8cm9zcy56d2lzbGVyQGxpbnV4LmludGVsLmNvbT4gd3JvdGU6Cj4+ IE9uIEZyaSwgRGVjIDIyLCAyMDE3IGF0IDAyOjUzOjQyUE0gLTA4MDAsIERhbiBXaWxsaWFtcyB3 cm90ZToKPj4+IE9uIFRodSwgRGVjIDIxLCAyMDE3IGF0IDEyOjMxIFBNLCBCcmljZSBHb2dsaW4g PGJyaWNlLmdvZ2xpbkBnbWFpbC5jb20+IHdyb3RlOgo+Pj4gPiBMZSAyMC8xMi8yMDE3IMOgIDIz OjQxLCBSb3NzIFp3aXNsZXIgYSDDqWNyaXQgOgo+Pj4gWy4uXQo+Pj4gPiBIZWxsbwo+Pj4gPgo+ Pj4gPiBJIGNhbiBjb25maXJtIHRoYXQgSFBDIHJ1bnRpbWVzIGFyZSBnb2luZyB0byB1c2UgdGhl c2UgcGF0Y2hlcyAoYXQgbGVhc3QKPj4+ID4gYWxsIHJ1bnRpbWVzIHRoYXQgdXNlIGh3bG9jIGZv ciB0b3BvbG9neSBkaXNjb3ZlcnksIGJ1dCB0aGF0J3MgdGhlIHZhc3QKPj4+ID4gbWFqb3JpdHkg b2YgSFBDIGFueXdheSkuCj4+PiA+Cj4+PiA+IFdlIHJlYWxseSBkaWRuJ3QgbGlrZSBLTkwgZXhw b3NpbmcgYSBoYWNreSBTTElUIHRhYmxlIFsxXS4gV2UgaGFkIHRvCj4+PiA+IGV4cGxpY2l0bHkg ZGV0ZWN0IHRoYXQgc3BlY2lmaWMgY3JhenkgdGFibGUgdG8gZmluZCBvdXQgd2hpY2ggTlVNQSBu b2Rlcwo+Pj4gPiB3ZXJlIGxvY2FsIHRvIHdoaWNoIGNvcmVzLCBhbmQgdG8gZmluZCBvdXQgd2hp Y2ggTlVNQSBub2RlcyB3ZXJlCj4+PiA+IEhCTS9NQ0RSQU0gb3IgRERSLiBBbmQgdGhlbiB3ZSBo YWQgdG8gaGlkZSB0aGUgU0xJVCB2YWx1ZXMgdG8gdGhlCj4+PiA+IGFwcGxpY2F0aW9uIGJlY2F1 c2UgdGhlIHJlcG9ydGVkIGxhdGVuY2llcyBkaWRuJ3QgbWF0Y2ggcmVhbGl0eS4gUXVpdGUKPj4+ ID4gYW5ub3lpbmcuCj4+PiA+Cj4+PiA+IFdpdGggUm9zcycgcGF0Y2hlcywgd2UgY2FuIGVhc2ls eSBnZXQgd2hhdCB3ZSBuZWVkOgo+Pj4gPiAqIHdoaWNoIE5VTUEgbm9kZXMgYXJlIGxvY2FsIHRv IHdoaWNoIENQVXM/IC9zeXMvZGV2aWNlcy9zeXN0ZW0vbm9kZS8KPj4+ID4gY2FuIG9ubHkgcmVw b3J0IGEgc2luZ2xlIGxvY2FsIG5vZGUgcGVyIENQVSAoZG9lc24ndCB3b3JrIGZvciBLTkwgYW5k Cj4+PiA+IHVwY29taW5nIGFyY2hpdGVjdHVyZXMgd2l0aCBIQk0rRERSKy4uLikKPj4+ID4gKiB3 aGljaCBOVU1BIG5vZGVzIGFyZSBzbG93L2Zhc3QgKGZvciBib3RoIGJhbmR3aWR0aCBhbmQgbGF0 ZW5jeSkKPj4+ID4gQW5kIHdlIGNhbiBzdGlsbCBsb29rIGF0IFNMSVQgdW5kZXIgL3N5cy9kZXZp Y2VzL3N5c3RlbS9ub2RlIGlmIHJlYWxseQo+Pj4gPiBuZWVkZWQuCj4+PiA+Cj4+PiA+IEFuZCBv ZiBjb3Vyc2UgaGF2aW5nIHRoaXMgaW4gc3lzZnMgaXMgbXVjaCBiZXR0ZXIgdGhhbiBwYXJzaW5n IEFDUEkKPj4+ID4gdGFibGVzIHRoYXQgYXJlIG9ubHkgYWNjZXNzaWJsZSB0byByb290IDopCj4+ Pgo+Pj4gT24gdGhpcyBwb2ludCwgaXQncyBub3QgY2xlYXIgdG8gbWUgdGhhdCB3ZSBzaG91bGQg YWxsb3cgdGhlc2Ugc3lzZnMKPj4+IGVudHJpZXMgdG8gYmUgd29ybGQgcmVhZGFibGUuIEdpdmVu IC9wcm9jL2lvbWVtIG5vdyBoaWRlcyBwaHlzaWNhbAo+Pj4gYWRkcmVzcyBpbmZvcm1hdGlvbiBm cm9tIG5vbi1yb290IHdlIGF0IGxlYXN0IG5lZWQgdG8gYmUgY2FyZWZ1bCBub3QKPj4+IHRvIHVu ZG8gdGhhdCB3aXRoIG5ldyBzeXNmcyBITUFUIGF0dHJpYnV0ZXMuCj4+Cj4+IFRoaXMgZW5hYmxp bmcgZG9lcyBub3QgZXhwb3NlIGFueSBwaHlzaWNhbCBhZGRyZXNzZXMgdG8gdXNlcnNwYWNlLiAg SXQgb25seQo+PiBwcm92aWRlcyBwZXJmb3JtYW5jZSBudW1iZXJzIGZyb20gdGhlIEhNQVQgYW5k IGFzc29jaWF0ZXMgdGhlbSB3aXRoIGV4aXN0aW5nCj4+IE5VTUEgbm9kZXMuICBBcmUgeW91IHdv cnJpZWQgdGhhdCBleHBvc2luZyBwZXJmb3JtYW5jZSBudW1iZXJzIHRvIG5vbi1yb290Cj4+IHVz ZXJzIHZpYSBzeXNmcyBwb3NlcyBhIHNlY3VyaXR5IHJpc2s/Cj4KPiBJdCdzIGFuIGluZm9ybWF0 aW9uIGRpc2Nsb3N1cmUgdGhhdCdzIG5vdCBjbGVhciB3ZSBuZWVkIHRvIG1ha2UgdG8KPiBub24t cm9vdCBwcm9jZXNzZXMuCj4KPiBJJ20gbW9yZSB3b3JyaWVkIGFib3V0IHVzZXJzcGFjZSBncm93 aW5nIGRlcGVuZGVuY2llcyBvbiB0aGUgYWJzb2x1dGUKPiBudW1iZXJzIHdoZW4gdGhvc2UgbnVt YmVycyBjYW4gY2hhbmdlIGZyb20gcGxhdGZvcm0gdG8gcGxhdGZvcm0uCj4gRGlmZmVyZW50aWF0 ZWQgbWVtb3J5IG9uIG9uZSBwbGF0Zm9ybSBtYXkgYmUgdGhlIGNvbW1vbiBtZW1vcnkgcG9vbCBv bgo+IGFub3RoZXIuCj4KPiBUbyBtZSB0aGlzIGhhcyBwYXJhbGxlbHMgd2l0aCBzdG9yYWdlIGRl dmljZSBoaW50aW5nIHdoZXJlCj4gc3BlY2lmaWNhdGlvbnMgbGlrZSBUMTAgaGF2ZSBhIGNvbXBs ZXggZW51bWVyYXRpb24gb2YgYWxsIHRoZQo+IHBlcmZvcm1hbmNlIGhpbnRzIHRoYXQgY2FuIGJl IHBhc3NlZCB0byB0aGUgZGV2aWNlLCBidXQgdGhlIExpbnV4Cj4gZW5hYmxpbmcgZWZmb3J0IGFp bXMgZm9yIGEgc2FuaXR6ZWQgc2V0IG9mIHJlbGF0aXZlIGhpbnRzIHRoYXQgbWFrZQo+IHNlbnNl LiBJdCdzIG1vcmUgZmxleGlibGUgaWYgdXNlcnNwYWNlIHNwZWNpZmllcyBhIHJlbGF0aXZlIGlu dGVudAo+IHJhdGhlciB0aGFuIGFuIGFic29sdXRlIHBlcmZvcm1hbmNlIHRhcmdldC4gUHV0dGlu ZyBhbGwgdGhlIEhNQVQKPiBpbmZvcm1hdGlvbiBpbnRvIHN5c2ZzIGdpdmVzIHVzZXJzcGFjZSBt b3JlIGluZm9ybWF0aW9uIHRoYW4gaXQgY291bGQKPiBwb3NzaWJseSBkbyBhbnl0aGluZyByZWFz b25hYmxlLCBhdCBsZWFzdCBvdXRzaWRlIG9mIHNwZWNpYWxpemVkIGFwcHMKPiB0aGF0IGFyZSBo YW5kIHR1bmVkIGZvciBhIGdpdmVuIGhhcmR3YXJlIHBsYXRmb3JtLgoKVGhhdCdzIGEgdmFsaWQg cG9pbnQgSU1PLgoKSXQgaXMgc29ydCBvZiB0ZW1wdGluZyB0byBleHBvc2UgZXZlcnl0aGluZyB0 byB1c2VyIHNwYWNlIHZlcmJhdGltLAplc3BlY2lhbGx5IGVhcmx5IGluIHRoZSBlbmFibGluZyBw cm9jZXNzIHdoZW4gdGhlIGtlcm5lbCBoYXMgbm90IHlldApmb3VuZCBzdWl0YWJsZSB3YXlzIHRv IHV0aWxpemUgdGhlIGdpdmVuIGluZm9ybWF0aW9uLCBidXQgdGhlIHZlcnkgYWN0Cm9mIGV4cG9z aW5nIGl0IG1heSBhZmZlY3Qgd2hhdCBjYW4gYmUgZG9uZSB3aXRoIGl0IGluIHRoZSBmdXR1cmUu CgpVc2VyIHNwYWNlIGludGVyZmFjZXMgbmVlZCB0byBzdGF5IGFyb3VuZCBhbmQgYmUgc3VwcG9y dGVkIGZvcmV2ZXIsIGF0CmxlYXN0IHBvdGVudGlhbGx5LCBzbyBhZGRpbmcgZXZlcnkgb25lIG9m IHRoZW0gaXMgYSBzZXJpb3VzCmNvbW1pdG1lbnQuCgpUaGFua3MsClJhZmFlbApfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpMaW51eC1udmRpbW0gbWFpbGlu ZyBsaXN0CkxpbnV4LW52ZGltbUBsaXN0cy4wMS5vcmcKaHR0cHM6Ly9saXN0cy4wMS5vcmcvbWFp bG1hbi9saXN0aW5mby9saW51eC1udmRpbW0K From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT Date: Sat, 23 Dec 2017 02:14:41 +0100 Message-ID: References: <20171214130032.GK16951@dhcp22.suse.cz> <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> <20171222232231.GA26715@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" To: Dan Williams Cc: Michal Hocko , "Box, David E" , Dave Hansen , "Zheng, Lv" , "linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org" , "Rafael J. Wysocki" , "Anaczkowski, Lukasz" , "Moore, Robert" , Matthew Wilcox , Linux ACPI , "Odzioba, Lukasz" , "Schmauss, Erik" , Len Brown , John Hubbard , linuxppc-dev , Jerome Glisse , devel-E0kO6a4B6psdnm+yROfE0A@public.gmane.org, "Kogut, Jaroslaw" , Linux MM , "Koss, Marcin" , Linux API , Brice Goglin , Nachi List-Id: linux-acpi@vger.kernel.org T24gU2F0LCBEZWMgMjMsIDIwMTcgYXQgMTI6NTcgQU0sIERhbiBXaWxsaWFtcyA8ZGFuLmoud2ls bGlhbXNAaW50ZWwuY29tPiB3cm90ZToKPiBPbiBGcmksIERlYyAyMiwgMjAxNyBhdCAzOjIyIFBN LCBSb3NzIFp3aXNsZXIKPiA8cm9zcy56d2lzbGVyQGxpbnV4LmludGVsLmNvbT4gd3JvdGU6Cj4+ IE9uIEZyaSwgRGVjIDIyLCAyMDE3IGF0IDAyOjUzOjQyUE0gLTA4MDAsIERhbiBXaWxsaWFtcyB3 cm90ZToKPj4+IE9uIFRodSwgRGVjIDIxLCAyMDE3IGF0IDEyOjMxIFBNLCBCcmljZSBHb2dsaW4g PGJyaWNlLmdvZ2xpbkBnbWFpbC5jb20+IHdyb3RlOgo+Pj4gPiBMZSAyMC8xMi8yMDE3IMOgIDIz OjQxLCBSb3NzIFp3aXNsZXIgYSDDqWNyaXQgOgo+Pj4gWy4uXQo+Pj4gPiBIZWxsbwo+Pj4gPgo+ Pj4gPiBJIGNhbiBjb25maXJtIHRoYXQgSFBDIHJ1bnRpbWVzIGFyZSBnb2luZyB0byB1c2UgdGhl c2UgcGF0Y2hlcyAoYXQgbGVhc3QKPj4+ID4gYWxsIHJ1bnRpbWVzIHRoYXQgdXNlIGh3bG9jIGZv ciB0b3BvbG9neSBkaXNjb3ZlcnksIGJ1dCB0aGF0J3MgdGhlIHZhc3QKPj4+ID4gbWFqb3JpdHkg b2YgSFBDIGFueXdheSkuCj4+PiA+Cj4+PiA+IFdlIHJlYWxseSBkaWRuJ3QgbGlrZSBLTkwgZXhw b3NpbmcgYSBoYWNreSBTTElUIHRhYmxlIFsxXS4gV2UgaGFkIHRvCj4+PiA+IGV4cGxpY2l0bHkg ZGV0ZWN0IHRoYXQgc3BlY2lmaWMgY3JhenkgdGFibGUgdG8gZmluZCBvdXQgd2hpY2ggTlVNQSBu b2Rlcwo+Pj4gPiB3ZXJlIGxvY2FsIHRvIHdoaWNoIGNvcmVzLCBhbmQgdG8gZmluZCBvdXQgd2hp Y2ggTlVNQSBub2RlcyB3ZXJlCj4+PiA+IEhCTS9NQ0RSQU0gb3IgRERSLiBBbmQgdGhlbiB3ZSBo YWQgdG8gaGlkZSB0aGUgU0xJVCB2YWx1ZXMgdG8gdGhlCj4+PiA+IGFwcGxpY2F0aW9uIGJlY2F1 c2UgdGhlIHJlcG9ydGVkIGxhdGVuY2llcyBkaWRuJ3QgbWF0Y2ggcmVhbGl0eS4gUXVpdGUKPj4+ ID4gYW5ub3lpbmcuCj4+PiA+Cj4+PiA+IFdpdGggUm9zcycgcGF0Y2hlcywgd2UgY2FuIGVhc2ls eSBnZXQgd2hhdCB3ZSBuZWVkOgo+Pj4gPiAqIHdoaWNoIE5VTUEgbm9kZXMgYXJlIGxvY2FsIHRv IHdoaWNoIENQVXM/IC9zeXMvZGV2aWNlcy9zeXN0ZW0vbm9kZS8KPj4+ID4gY2FuIG9ubHkgcmVw b3J0IGEgc2luZ2xlIGxvY2FsIG5vZGUgcGVyIENQVSAoZG9lc24ndCB3b3JrIGZvciBLTkwgYW5k Cj4+PiA+IHVwY29taW5nIGFyY2hpdGVjdHVyZXMgd2l0aCBIQk0rRERSKy4uLikKPj4+ID4gKiB3 aGljaCBOVU1BIG5vZGVzIGFyZSBzbG93L2Zhc3QgKGZvciBib3RoIGJhbmR3aWR0aCBhbmQgbGF0 ZW5jeSkKPj4+ID4gQW5kIHdlIGNhbiBzdGlsbCBsb29rIGF0IFNMSVQgdW5kZXIgL3N5cy9kZXZp Y2VzL3N5c3RlbS9ub2RlIGlmIHJlYWxseQo+Pj4gPiBuZWVkZWQuCj4+PiA+Cj4+PiA+IEFuZCBv ZiBjb3Vyc2UgaGF2aW5nIHRoaXMgaW4gc3lzZnMgaXMgbXVjaCBiZXR0ZXIgdGhhbiBwYXJzaW5n IEFDUEkKPj4+ID4gdGFibGVzIHRoYXQgYXJlIG9ubHkgYWNjZXNzaWJsZSB0byByb290IDopCj4+ Pgo+Pj4gT24gdGhpcyBwb2ludCwgaXQncyBub3QgY2xlYXIgdG8gbWUgdGhhdCB3ZSBzaG91bGQg YWxsb3cgdGhlc2Ugc3lzZnMKPj4+IGVudHJpZXMgdG8gYmUgd29ybGQgcmVhZGFibGUuIEdpdmVu IC9wcm9jL2lvbWVtIG5vdyBoaWRlcyBwaHlzaWNhbAo+Pj4gYWRkcmVzcyBpbmZvcm1hdGlvbiBm cm9tIG5vbi1yb290IHdlIGF0IGxlYXN0IG5lZWQgdG8gYmUgY2FyZWZ1bCBub3QKPj4+IHRvIHVu ZG8gdGhhdCB3aXRoIG5ldyBzeXNmcyBITUFUIGF0dHJpYnV0ZXMuCj4+Cj4+IFRoaXMgZW5hYmxp bmcgZG9lcyBub3QgZXhwb3NlIGFueSBwaHlzaWNhbCBhZGRyZXNzZXMgdG8gdXNlcnNwYWNlLiAg SXQgb25seQo+PiBwcm92aWRlcyBwZXJmb3JtYW5jZSBudW1iZXJzIGZyb20gdGhlIEhNQVQgYW5k IGFzc29jaWF0ZXMgdGhlbSB3aXRoIGV4aXN0aW5nCj4+IE5VTUEgbm9kZXMuICBBcmUgeW91IHdv cnJpZWQgdGhhdCBleHBvc2luZyBwZXJmb3JtYW5jZSBudW1iZXJzIHRvIG5vbi1yb290Cj4+IHVz ZXJzIHZpYSBzeXNmcyBwb3NlcyBhIHNlY3VyaXR5IHJpc2s/Cj4KPiBJdCdzIGFuIGluZm9ybWF0 aW9uIGRpc2Nsb3N1cmUgdGhhdCdzIG5vdCBjbGVhciB3ZSBuZWVkIHRvIG1ha2UgdG8KPiBub24t cm9vdCBwcm9jZXNzZXMuCj4KPiBJJ20gbW9yZSB3b3JyaWVkIGFib3V0IHVzZXJzcGFjZSBncm93 aW5nIGRlcGVuZGVuY2llcyBvbiB0aGUgYWJzb2x1dGUKPiBudW1iZXJzIHdoZW4gdGhvc2UgbnVt YmVycyBjYW4gY2hhbmdlIGZyb20gcGxhdGZvcm0gdG8gcGxhdGZvcm0uCj4gRGlmZmVyZW50aWF0 ZWQgbWVtb3J5IG9uIG9uZSBwbGF0Zm9ybSBtYXkgYmUgdGhlIGNvbW1vbiBtZW1vcnkgcG9vbCBv bgo+IGFub3RoZXIuCj4KPiBUbyBtZSB0aGlzIGhhcyBwYXJhbGxlbHMgd2l0aCBzdG9yYWdlIGRl dmljZSBoaW50aW5nIHdoZXJlCj4gc3BlY2lmaWNhdGlvbnMgbGlrZSBUMTAgaGF2ZSBhIGNvbXBs ZXggZW51bWVyYXRpb24gb2YgYWxsIHRoZQo+IHBlcmZvcm1hbmNlIGhpbnRzIHRoYXQgY2FuIGJl IHBhc3NlZCB0byB0aGUgZGV2aWNlLCBidXQgdGhlIExpbnV4Cj4gZW5hYmxpbmcgZWZmb3J0IGFp bXMgZm9yIGEgc2FuaXR6ZWQgc2V0IG9mIHJlbGF0aXZlIGhpbnRzIHRoYXQgbWFrZQo+IHNlbnNl LiBJdCdzIG1vcmUgZmxleGlibGUgaWYgdXNlcnNwYWNlIHNwZWNpZmllcyBhIHJlbGF0aXZlIGlu dGVudAo+IHJhdGhlciB0aGFuIGFuIGFic29sdXRlIHBlcmZvcm1hbmNlIHRhcmdldC4gUHV0dGlu ZyBhbGwgdGhlIEhNQVQKPiBpbmZvcm1hdGlvbiBpbnRvIHN5c2ZzIGdpdmVzIHVzZXJzcGFjZSBt b3JlIGluZm9ybWF0aW9uIHRoYW4gaXQgY291bGQKPiBwb3NzaWJseSBkbyBhbnl0aGluZyByZWFz b25hYmxlLCBhdCBsZWFzdCBvdXRzaWRlIG9mIHNwZWNpYWxpemVkIGFwcHMKPiB0aGF0IGFyZSBo YW5kIHR1bmVkIGZvciBhIGdpdmVuIGhhcmR3YXJlIHBsYXRmb3JtLgoKVGhhdCdzIGEgdmFsaWQg cG9pbnQgSU1PLgoKSXQgaXMgc29ydCBvZiB0ZW1wdGluZyB0byBleHBvc2UgZXZlcnl0aGluZyB0 byB1c2VyIHNwYWNlIHZlcmJhdGltLAplc3BlY2lhbGx5IGVhcmx5IGluIHRoZSBlbmFibGluZyBw cm9jZXNzIHdoZW4gdGhlIGtlcm5lbCBoYXMgbm90IHlldApmb3VuZCBzdWl0YWJsZSB3YXlzIHRv IHV0aWxpemUgdGhlIGdpdmVuIGluZm9ybWF0aW9uLCBidXQgdGhlIHZlcnkgYWN0Cm9mIGV4cG9z aW5nIGl0IG1heSBhZmZlY3Qgd2hhdCBjYW4gYmUgZG9uZSB3aXRoIGl0IGluIHRoZSBmdXR1cmUu CgpVc2VyIHNwYWNlIGludGVyZmFjZXMgbmVlZCB0byBzdGF5IGFyb3VuZCBhbmQgYmUgc3VwcG9y dGVkIGZvcmV2ZXIsIGF0CmxlYXN0IHBvdGVudGlhbGx5LCBzbyBhZGRpbmcgZXZlcnkgb25lIG9m IHRoZW0gaXMgYSBzZXJpb3VzCmNvbW1pdG1lbnQuCgpUaGFua3MsClJhZmFlbApfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpMaW51eC1udmRpbW0gbWFpbGlu ZyBsaXN0CkxpbnV4LW52ZGltbUBsaXN0cy4wMS5vcmcKaHR0cHM6Ly9saXN0cy4wMS5vcmcvbWFp bG1hbi9saXN0aW5mby9saW51eC1udmRpbW0K From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757212AbdLWBOs (ORCPT ); Fri, 22 Dec 2017 20:14:48 -0500 Received: from mail-ot0-f195.google.com ([74.125.82.195]:33865 "EHLO mail-ot0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757161AbdLWBOm (ORCPT ); Fri, 22 Dec 2017 20:14:42 -0500 X-Google-Smtp-Source: ACJfBouL4bPYWuDj3bD9wF9gdlKjD82M26WpE/jchsnWgbLuz0caOyDNRg3RB1hmc4HR91CifuE1FodH8l5FP323QSA= MIME-Version: 1.0 In-Reply-To: References: <20171214130032.GK16951@dhcp22.suse.cz> <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> <20171222232231.GA26715@linux.intel.com> From: "Rafael J. Wysocki" Date: Sat, 23 Dec 2017 02:14:41 +0100 X-Google-Sender-Auth: 6S7g11AzoPHzYoG2LL9JYJssMUo Message-ID: Subject: Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT To: Dan Williams Cc: Ross Zwisler , Brice Goglin , Matthew Wilcox , 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id vBN1Evq5018982 On Sat, Dec 23, 2017 at 12:57 AM, Dan Williams wrote: > On Fri, Dec 22, 2017 at 3:22 PM, Ross Zwisler > wrote: >> On Fri, Dec 22, 2017 at 02:53:42PM -0800, Dan Williams wrote: >>> On Thu, Dec 21, 2017 at 12:31 PM, Brice Goglin wrote: >>> > Le 20/12/2017 à 23:41, Ross Zwisler a écrit : >>> [..] >>> > Hello >>> > >>> > I can confirm that HPC runtimes are going to use these patches (at least >>> > all runtimes that use hwloc for topology discovery, but that's the vast >>> > majority of HPC anyway). >>> > >>> > We really didn't like KNL exposing a hacky SLIT table [1]. We had to >>> > explicitly detect that specific crazy table to find out which NUMA nodes >>> > were local to which cores, and to find out which NUMA nodes were >>> > HBM/MCDRAM or DDR. And then we had to hide the SLIT values to the >>> > application because the reported latencies didn't match reality. Quite >>> > annoying. >>> > >>> > With Ross' patches, we can easily get what we need: >>> > * which NUMA nodes are local to which CPUs? /sys/devices/system/node/ >>> > can only report a single local node per CPU (doesn't work for KNL and >>> > upcoming architectures with HBM+DDR+...) >>> > * which NUMA nodes are slow/fast (for both bandwidth and latency) >>> > And we can still look at SLIT under /sys/devices/system/node if really >>> > needed. >>> > >>> > And of course having this in sysfs is much better than parsing ACPI >>> > tables that are only accessible to root :) >>> >>> On this point, it's not clear to me that we should allow these sysfs >>> entries to be world readable. Given /proc/iomem now hides physical >>> address information from non-root we at least need to be careful not >>> to undo that with new sysfs HMAT attributes. >> >> This enabling does not expose any physical addresses to userspace. It only >> provides performance numbers from the HMAT and associates them with existing >> NUMA nodes. Are you worried that exposing performance numbers to non-root >> users via sysfs poses a security risk? > > It's an information disclosure that's not clear we need to make to > non-root processes. > > I'm more worried about userspace growing dependencies on the absolute > numbers when those numbers can change from platform to platform. > Differentiated memory on one platform may be the common memory pool on > another. > > To me this has parallels with storage device hinting where > specifications like T10 have a complex enumeration of all the > performance hints that can be passed to the device, but the Linux > enabling effort aims for a sanitzed set of relative hints that make > sense. It's more flexible if userspace specifies a relative intent > rather than an absolute performance target. Putting all the HMAT > information into sysfs gives userspace more information than it could > possibly do anything reasonable, at least outside of specialized apps > that are hand tuned for a given hardware platform. That's a valid point IMO. It is sort of tempting to expose everything to user space verbatim, especially early in the enabling process when the kernel has not yet found suitable ways to utilize the given information, but the very act of exposing it may affect what can be done with it in the future. User space interfaces need to stay around and be supported forever, at least potentially, so adding every one of them is a serious commitment. Thanks, Rafael From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-f200.google.com (mail-ot0-f200.google.com [74.125.82.200]) by kanga.kvack.org (Postfix) with ESMTP id C0AEB6B0266 for ; Fri, 22 Dec 2017 20:14:43 -0500 (EST) Received: by mail-ot0-f200.google.com with SMTP id o43so11353317otd.12 for ; Fri, 22 Dec 2017 17:14:43 -0800 (PST) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id d46sor7038466otf.133.2017.12.22.17.14.42 for (Google Transport Security); Fri, 22 Dec 2017 17:14:42 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20171214130032.GK16951@dhcp22.suse.cz> <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> <20171222232231.GA26715@linux.intel.com> From: "Rafael J. Wysocki" Date: Sat, 23 Dec 2017 02:14:41 +0100 Message-ID: Subject: Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: Dan Williams Cc: Ross Zwisler , Brice Goglin , Matthew Wilcox , 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 On Sat, Dec 23, 2017 at 12:57 AM, Dan Williams w= rote: > On Fri, Dec 22, 2017 at 3:22 PM, Ross Zwisler > wrote: >> On Fri, Dec 22, 2017 at 02:53:42PM -0800, Dan Williams wrote: >>> On Thu, Dec 21, 2017 at 12:31 PM, Brice Goglin = wrote: >>> > Le 20/12/2017 =C3=A0 23:41, Ross Zwisler a =C3=A9crit : >>> [..] >>> > Hello >>> > >>> > I can confirm that HPC runtimes are going to use these patches (at le= ast >>> > all runtimes that use hwloc for topology discovery, but that's the va= st >>> > majority of HPC anyway). >>> > >>> > We really didn't like KNL exposing a hacky SLIT table [1]. We had to >>> > explicitly detect that specific crazy table to find out which NUMA no= des >>> > were local to which cores, and to find out which NUMA nodes were >>> > HBM/MCDRAM or DDR. And then we had to hide the SLIT values to the >>> > application because the reported latencies didn't match reality. Quit= e >>> > annoying. >>> > >>> > With Ross' patches, we can easily get what we need: >>> > * which NUMA nodes are local to which CPUs? /sys/devices/system/node/ >>> > can only report a single local node per CPU (doesn't work for KNL and >>> > upcoming architectures with HBM+DDR+...) >>> > * which NUMA nodes are slow/fast (for both bandwidth and latency) >>> > And we can still look at SLIT under /sys/devices/system/node if reall= y >>> > needed. >>> > >>> > And of course having this in sysfs is much better than parsing ACPI >>> > tables that are only accessible to root :) >>> >>> On this point, it's not clear to me that we should allow these sysfs >>> entries to be world readable. Given /proc/iomem now hides physical >>> address information from non-root we at least need to be careful not >>> to undo that with new sysfs HMAT attributes. >> >> This enabling does not expose any physical addresses to userspace. It o= nly >> provides performance numbers from the HMAT and associates them with exis= ting >> NUMA nodes. Are you worried that exposing performance numbers to non-ro= ot >> users via sysfs poses a security risk? > > It's an information disclosure that's not clear we need to make to > non-root processes. > > I'm more worried about userspace growing dependencies on the absolute > numbers when those numbers can change from platform to platform. > Differentiated memory on one platform may be the common memory pool on > another. > > To me this has parallels with storage device hinting where > specifications like T10 have a complex enumeration of all the > performance hints that can be passed to the device, but the Linux > enabling effort aims for a sanitzed set of relative hints that make > sense. It's more flexible if userspace specifies a relative intent > rather than an absolute performance target. Putting all the HMAT > information into sysfs gives userspace more information than it could > possibly do anything reasonable, at least outside of specialized apps > that are hand tuned for a given hardware platform. That's a valid point IMO. It is sort of tempting to expose everything to user space verbatim, especially early in the enabling process when the kernel has not yet found suitable ways to utilize the given information, but the very act of exposing it may affect what can be done with it in the future. User space interfaces need to stay around and be supported forever, at least potentially, so adding every one of them is a serious commitment. Thanks, Rafael -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-x243.google.com (mail-ot0-x243.google.com [IPv6:2607:f8b0:4003:c0f::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3z3S8h3dnwzF0CT for ; Sat, 23 Dec 2017 12:14:44 +1100 (AEDT) Received: by mail-ot0-x243.google.com with SMTP id q39so20015846otb.8 for ; Fri, 22 Dec 2017 17:14:44 -0800 (PST) MIME-Version: 1.0 Sender: rjwysocki@gmail.com In-Reply-To: References: <20171214130032.GK16951@dhcp22.suse.cz> <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> <20171222232231.GA26715@linux.intel.com> From: "Rafael J. Wysocki" Date: Sat, 23 Dec 2017 02:14:41 +0100 Message-ID: Subject: Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT To: Dan Williams Cc: Ross Zwisler , Brice Goglin , Matthew Wilcox , 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 Content-Type: text/plain; charset="UTF-8" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Sat, Dec 23, 2017 at 12:57 AM, Dan Williams w= rote: > On Fri, Dec 22, 2017 at 3:22 PM, Ross Zwisler > wrote: >> On Fri, Dec 22, 2017 at 02:53:42PM -0800, Dan Williams wrote: >>> On Thu, Dec 21, 2017 at 12:31 PM, Brice Goglin = wrote: >>> > Le 20/12/2017 =C3=A0 23:41, Ross Zwisler a =C3=A9crit : >>> [..] >>> > Hello >>> > >>> > I can confirm that HPC runtimes are going to use these patches (at le= ast >>> > all runtimes that use hwloc for topology discovery, but that's the va= st >>> > majority of HPC anyway). >>> > >>> > We really didn't like KNL exposing a hacky SLIT table [1]. We had to >>> > explicitly detect that specific crazy table to find out which NUMA no= des >>> > were local to which cores, and to find out which NUMA nodes were >>> > HBM/MCDRAM or DDR. And then we had to hide the SLIT values to the >>> > application because the reported latencies didn't match reality. Quit= e >>> > annoying. >>> > >>> > With Ross' patches, we can easily get what we need: >>> > * which NUMA nodes are local to which CPUs? /sys/devices/system/node/ >>> > can only report a single local node per CPU (doesn't work for KNL and >>> > upcoming architectures with HBM+DDR+...) >>> > * which NUMA nodes are slow/fast (for both bandwidth and latency) >>> > And we can still look at SLIT under /sys/devices/system/node if reall= y >>> > needed. >>> > >>> > And of course having this in sysfs is much better than parsing ACPI >>> > tables that are only accessible to root :) >>> >>> On this point, it's not clear to me that we should allow these sysfs >>> entries to be world readable. Given /proc/iomem now hides physical >>> address information from non-root we at least need to be careful not >>> to undo that with new sysfs HMAT attributes. >> >> This enabling does not expose any physical addresses to userspace. It o= nly >> provides performance numbers from the HMAT and associates them with exis= ting >> NUMA nodes. Are you worried that exposing performance numbers to non-ro= ot >> users via sysfs poses a security risk? > > It's an information disclosure that's not clear we need to make to > non-root processes. > > I'm more worried about userspace growing dependencies on the absolute > numbers when those numbers can change from platform to platform. > Differentiated memory on one platform may be the common memory pool on > another. > > To me this has parallels with storage device hinting where > specifications like T10 have a complex enumeration of all the > performance hints that can be passed to the device, but the Linux > enabling effort aims for a sanitzed set of relative hints that make > sense. It's more flexible if userspace specifies a relative intent > rather than an absolute performance target. Putting all the HMAT > information into sysfs gives userspace more information than it could > possibly do anything reasonable, at least outside of specialized apps > that are hand tuned for a given hardware platform. That's a valid point IMO. It is sort of tempting to expose everything to user space verbatim, especially early in the enabling process when the kernel has not yet found suitable ways to utilize the given information, but the very act of exposing it may affect what can be done with it in the future. User space interfaces need to stay around and be supported forever, at least potentially, so adding every one of them is a serious commitment. Thanks, Rafael From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============0120476879443612132==" MIME-Version: 1.0 From: Rafael J. Wysocki Subject: Re: [Devel] [PATCH v3 0/3] create sysfs representation of ACPI HMAT Date: Sat, 23 Dec 2017 02:14:41 +0100 Message-ID: In-Reply-To: CAPcyv4j95rWmFM5NDvoRJakwVE5YUgcipQW2Ju+40+FD6vYs+Q@mail.gmail.com List-ID: To: devel@acpica.org --===============0120476879443612132== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Sat, Dec 23, 2017 at 12:57 AM, Dan Williams = wrote: > On Fri, Dec 22, 2017 at 3:22 PM, Ross Zwisler > wrote: >> On Fri, Dec 22, 2017 at 02:53:42PM -0800, Dan Williams wrote: >>> On Thu, Dec 21, 2017 at 12:31 PM, Brice Goglin wrote: >>> > Le 20/12/2017 =C3=A0 23:41, Ross Zwisler a =C3=A9crit : >>> [..] >>> > Hello >>> > >>> > I can confirm that HPC runtimes are going to use these patches (at le= ast >>> > all runtimes that use hwloc for topology discovery, but that's the va= st >>> > majority of HPC anyway). >>> > >>> > We really didn't like KNL exposing a hacky SLIT table [1]. We had to >>> > explicitly detect that specific crazy table to find out which NUMA no= des >>> > were local to which cores, and to find out which NUMA nodes were >>> > HBM/MCDRAM or DDR. And then we had to hide the SLIT values to the >>> > application because the reported latencies didn't match reality. Quite >>> > annoying. >>> > >>> > With Ross' patches, we can easily get what we need: >>> > * which NUMA nodes are local to which CPUs? /sys/devices/system/node/ >>> > can only report a single local node per CPU (doesn't work for KNL and >>> > upcoming architectures with HBM+DDR+...) >>> > * which NUMA nodes are slow/fast (for both bandwidth and latency) >>> > And we can still look at SLIT under /sys/devices/system/node if really >>> > needed. >>> > >>> > And of course having this in sysfs is much better than parsing ACPI >>> > tables that are only accessible to root :) >>> >>> On this point, it's not clear to me that we should allow these sysfs >>> entries to be world readable. Given /proc/iomem now hides physical >>> address information from non-root we at least need to be careful not >>> to undo that with new sysfs HMAT attributes. >> >> This enabling does not expose any physical addresses to userspace. It o= nly >> provides performance numbers from the HMAT and associates them with exis= ting >> NUMA nodes. Are you worried that exposing performance numbers to non-ro= ot >> users via sysfs poses a security risk? > > It's an information disclosure that's not clear we need to make to > non-root processes. > > I'm more worried about userspace growing dependencies on the absolute > numbers when those numbers can change from platform to platform. > Differentiated memory on one platform may be the common memory pool on > another. > > To me this has parallels with storage device hinting where > specifications like T10 have a complex enumeration of all the > performance hints that can be passed to the device, but the Linux > enabling effort aims for a sanitzed set of relative hints that make > sense. It's more flexible if userspace specifies a relative intent > rather than an absolute performance target. Putting all the HMAT > information into sysfs gives userspace more information than it could > possibly do anything reasonable, at least outside of specialized apps > that are hand tuned for a given hardware platform. That's a valid point IMO. It is sort of tempting to expose everything to user space verbatim, especially early in the enabling process when the kernel has not yet found suitable ways to utilize the given information, but the very act of exposing it may affect what can be done with it in the future. User space interfaces need to stay around and be supported forever, at least potentially, so adding every one of them is a serious commitment. Thanks, Rafael --===============0120476879443612132==--