lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 23 Dec 2017 10:44:34 +0530
From:   Anshuman Khandual <>
To:     Dave Hansen <>,
        Anshuman Khandual <>,
        Ross Zwisler <>,
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 <>,,,,
Subject: Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT

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.

Powered by blists - more mailing lists