linux-kernel - Re: [RFC PATCH v4 2/7] mm/demotion: Expose per node memory tier to sysfs

lists.openwall.net		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 linux-cve-announce 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:   Mon, 6 Jun 2022 15:59:20 +0100
From:   Jonathan Cameron <Jonathan.Cameron@...wei.com>
To:     Aneesh Kumar K V <aneesh.kumar@...ux.ibm.com>
CC:     <linux-mm@...ck.org>, <akpm@...ux-foundation.org>,
        Huang Ying <ying.huang@...el.com>,
        Greg Thelen <gthelen@...gle.com>,
        Yang Shi <shy828301@...il.com>,
        Davidlohr Bueso <dave@...olabs.net>,
        Tim C Chen <tim.c.chen@...el.com>,
        Brice Goglin <brice.goglin@...il.com>,
        Michal Hocko <mhocko@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Hesham Almatary <hesham.almatary@...wei.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Alistair Popple <apopple@...dia.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Feng Tang <feng.tang@...el.com>,
        Jagdish Gediya <jvgediya@...ux.ibm.com>,
        Baolin Wang <baolin.wang@...ux.alibaba.com>,
        David Rientjes <rientjes@...gle.com>
Subject: Re: [RFC PATCH v4 2/7] mm/demotion: Expose per node memory tier to
 sysfs

On Fri, 3 Jun 2022 14:10:47 +0530
Aneesh Kumar K V <aneesh.kumar@...ux.ibm.com> wrote:

> On 5/27/22 7:45 PM, Jonathan Cameron wrote:
> > On Fri, 27 May 2022 17:55:23 +0530
> > "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com> wrote:
> >   
> >> From: Jagdish Gediya <jvgediya@...ux.ibm.com>
> >>
> >> Add support to read/write the memory tierindex for a NUMA node.
> >>
> >> /sys/devices/system/node/nodeN/memtier
> >>
> >> where N = node id
> >>
> >> When read, It list the memory tier that the node belongs to.
> >>
> >> When written, the kernel moves the node into the specified
> >> memory tier, the tier assignment of all other nodes are not
> >> affected.
> >>
> >> If the memory tier does not exist, writing to the above file
> >> create the tier and assign the NUMA node to that tier.  
> > creates
> > 
> > There was some discussion in v2 of Wei Xu's RFC that what matter
> > for creation is the rank, not the tier number.
> > 
> > My suggestion is move to an explicit creation file such as
> > memtier/create_tier_from_rank
> > to which writing the rank gives results in a new tier
> > with the next device ID and requested rank.  
> 
> I think the below workflow is much simpler.
> 
> :/sys/devices/system# cat memtier/memtier1/nodelist
> 1-3
> :/sys/devices/system# cat node/node1/memtier
> 1
> :/sys/devices/system# ls memtier/memtier*
> nodelist  power  rank  subsystem  uevent
> /sys/devices/system# ls memtier/
> default_rank  max_tier  memtier1  power  uevent
> :/sys/devices/system# echo 2 > node/node1/memtier
> :/sys/devices/system#
> 
> :/sys/devices/system# ls memtier/
> default_rank  max_tier  memtier1  memtier2  power  uevent
> :/sys/devices/system# cat memtier/memtier1/nodelist
> 2-3
> :/sys/devices/system# cat memtier/memtier2/nodelist
> 1
> :/sys/devices/system#
> 
> ie, to create a tier we just write the tier id/tier index to 
> node/nodeN/memtier file. That will create a new memory tier if needed 
> and add the node to that specific memory tier. Since for now we are 
> having 1:1 mapping between tier index to rank value, we can derive the 
> rank value from the memory tier index.
> 
> For dynamic memory tier support, we can assign a rank value such that 
> new memory tiers are always created such that it comes last in the 
> demotion order.

I'm not keen on having to pass through an intermediate state where
the rank may well be wrong, but I guess it's not that harmful even
if it feels wrong ;)

Races are potentially a bit of a pain though depending on what we
expect the usage model to be.

There are patterns (CXL regions for example) of guaranteeing the
'right' device is created by doing something like 

cat create_tier > temp.txt 
#(temp gets 2 for example on first call then
# next read of this file gets 3 etc)

cat temp.txt > create_tier
# will fail if there hasn't been a read of the same value

Assuming all software keeps to the model, then there are no
race conditions over creation.  Otherwise we have two new
devices turn up very close to each other and userspace scripting
tries to create two new tiers - if it races they may end up in
the same tier when that wasn't the intent.  Then code to set
the rank also races and we get two potentially very different
memories in a tier with a randomly selected rank.

Fun and games...  And a fine illustration why sysfs based 'device'
creation is tricky to get right (and lots of cases in the kernel
don't).

Jonathan


> 
> -aneesh
> 
> 
> 
>