linux-kernel - Re: [RFC PATCH 1/2] mm/demotion: Expose memory type details via 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]

Message-ID: <CAAPL-u9TKbHGztAF=r-io3gkX7gorUunS2UfstudCWuihrA=0g@mail.gmail.com>
Date:   Fri, 26 Aug 2022 01:00:57 -0700
From:   Wei Xu <weixugc@...gle.com>
To:     Aneesh Kumar K V <aneesh.kumar@...ux.ibm.com>
Cc:     "Huang, Ying" <ying.huang@...el.com>,
        Linux MM <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Yang Shi <shy828301@...il.com>,
        Davidlohr Bueso <dave@...olabs.net>,
        Tim C Chen <tim.c.chen@...el.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>,
        Johannes Weiner <hannes@...xchg.org>, jvgediya.oss@...il.com,
        Bharata B Rao <bharata@....com>
Subject: Re: [RFC PATCH 1/2] mm/demotion: Expose memory type details via sysfs

On Thu, Aug 25, 2022 at 8:00 PM Aneesh Kumar K V
<aneesh.kumar@...ux.ibm.com> wrote:
>
> On 8/26/22 7:20 AM, Huang, Ying wrote:
> > "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com> writes:
> >
> >> This patch adds /sys/devices/virtual/memtier/ where all memory tier related
> >> details can be found. All allocated memory types will be listed there as
> >> /sys/devices/virtual/memtier/memtypeN/
> >
> > Another choice is to make memory types and memory tiers system devices.
> > That is,
> >
> > /sys/devices/system/memory_type/memory_typeN
> > /sys/devices/system/memory_tier/memory_tierN
> >
>
> subsys_system_register() documentation says
>
>  * Do not use this interface for anything new, it exists for compatibility
>  * with bad ideas only. New subsystems should use plain subsystems; and
>  * add the subsystem-wide attributes should be added to the subsystem
>  * directory itself and not some create fake root-device placed in
>  * /sys/devices/system/<name>.
>
> memtier being a virtual device, I was under the impression that /sys/devices/virtual
> is the recommended place.
>
> > That looks more natural to me.  Because we already have "node" and
> > "memory" devices there.  Why don't you put memory types and memory tiers
> > there?
> >
> > And, I think we shouldn't put "memory_type" in the "memory_tier"
> > directory.  "memory_type" isn't a part of "memory_tier".
> >
>
> I was looking consolidating both memory tier and memory type into the same sysfs subsystem.
> Your recommendation imply we create two subsystem memory_tier and memtype. I was
> trying to avoid that. May be a generic term like "memory_tiering" can help to
> consolidate all tiering related details there?
>

A generic term "memory_tiering" sounds good to me.

Given that this will be a user-facing, stable kernel API, I think we'd
better to only add what is most useful for userspace and don't have to
mirror the kernel internal data structures in this interface.

My understanding is that we haven't fully settled down on how to
customize memory tiers from userspace.  So we don't have to show
memory_type yet, which is a kernel data structure at this point.

The userspace does need to know what are the memory tiers and which
NUMA nodes are included in each memory tier.  How about we provide the
"nodelist" interface for each memory tier as in the original proposal?

The userspace would also like to know which memory tiers/nodes belong
to the top tiers (the promotion targets).  We can provide a "toptiers"
or "toptiers_nodelist" interface to report that.

Both should still be useful even if we decide to add memory_type for
memory tier customization.

> >> The nodes which are part of a specific memory type can be listed via
> >> /sys/devices/system/memtier/memtypeN/nodes.
> >
> > How about create links to /sys/devices/system/node/nodeN in
> > "memory_type".  But I'm OK to have "nodes" file too.
> >
> >> The adistance value of a specific memory type can be listed via
> >> /sys/devices/system/memtier/memtypeN/adistance.
> >>
> >> A directory listing looks like:
> >> :/sys/devices/virtual/memtier# tree memtype1
> >> memtype1
> >> ├── adistance
> >
> > Why not just use "abstract_distance"?  This is user space interface,
> > it's better to be intuitive.
> >
> >> ├── nodes
> >> ├── subsystem -> ../../../../bus/memtier
> >> └── uevent
> >>
> >> Since we will be using struct device to expose details via sysfs, drop struct
> >> kref and use struct device for refcounting the memtype.
> >>
> >
> > Best Regards,
> > Huang, Ying
>