linux-kernel - Re: RFC: Memory Tiering Kernel Interfaces (v3)

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1281d918c07b05ac82aee290018ad08d212e0aaa.camel@intel.com>
Date:   Sun, 29 May 2022 12:31:30 +0800
From:   Ying Huang <ying.huang@...el.com>
To:     Wei Xu <weixugc@...gle.com>,
        Aneesh Kumar K V <aneesh.kumar@...ux.ibm.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        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>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Alistair Popple <apopple@...dia.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Feng Tang <feng.tang@...el.com>, Linux MM <linux-mm@...ck.org>,
        Jagdish Gediya <jvgediya@...ux.ibm.com>,
        Baolin Wang <baolin.wang@...ux.alibaba.com>,
        David Rientjes <rientjes@...gle.com>
Subject: Re: RFC: Memory Tiering Kernel Interfaces (v3)

On Fri, 2022-05-27 at 09:30 -0700, Wei Xu wrote:
> On Fri, May 27, 2022 at 6:41 AM Aneesh Kumar K V
> <aneesh.kumar@...ux.ibm.com> wrote:
> > 
> > On 5/27/22 2:52 AM, Wei Xu wrote:
> > 
> > >    The order of memory tiers is determined by their rank values, not by
> > >    their memtier device names.
> > > 
> > >    - /sys/devices/system/memtier/possible
> > > 
> > >      Format: ordered list of "memtier(rank)"
> > >      Example: 0(64), 1(128), 2(192)
> > > 
> > >      Read-only.  When read, list all available memory tiers and their
> > >      associated ranks, ordered by the rank values (from the highest
> > >       tier to the lowest tier).
> > > 
> > 
> > Did we discuss the need for this? I haven't done this in the patch
> > series I sent across.
> 
> The "possible" file is only needed if we decide to hide the
> directories of memtiers that have no nodes.  We can remove this
> interface and always show all memtier directories to keep things
> simpler.

When discussed offline, Tim Chen pointed out that with the proposed
interface, it's unconvenient to know the position of a given memory tier
in all memory tiers.  We must sort "rank" of all memory tiers to know
that.  "possible" file can be used for that.  Although "possible" file
can be generated with a shell script, it's more convenient to show it
directly.

Another way to address the issue is to add memtierN/pos for each memory
tier as suggested by Tim.  It's readonly and will show position of
"memtierN" in all memory tiers.  It's even better to show the relative
postion to the default memory tier (DRAM with CPU). That is, the
position of DRAM memory tier is 0.

Unlike memory tier device ID or rank, the position is relative and
dynamic.

Best Regards,
Huang, Ying