From: Aneesh Kumar K V <aneesh.kumar@linux.ibm.com>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
Wei Xu <weixugc@google.com>, Yang Shi <shy828301@gmail.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Tim C Chen <tim.c.chen@intel.com>,
Michal Hocko <mhocko@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Hesham Almatary <hesham.almatary@huawei.com>,
Dave Hansen <dave.hansen@intel.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Alistair Popple <apopple@nvidia.com>,
Dan Williams <dan.j.williams@intel.com>,
Johannes Weiner <hannes@cmpxchg.org>,
jvgediya.oss@gmail.com, Bharata B Rao <bharata@amd.com>
Subject: Re: [RFC PATCH 1/2] mm/demotion: Expose memory type details via sysfs
Date: Fri, 26 Aug 2022 08:07:28 +0530 [thread overview]
Message-ID: <e2f20ae9-5761-c170-a4e7-121d6b69ebfb@linux.ibm.com> (raw)
In-Reply-To: <877d2v3h8s.fsf@yhuang6-desk2.ccr.corp.intel.com>
On 8/26/22 7:20 AM, Huang, Ying wrote:
> "Aneesh Kumar K.V" <aneesh.kumar@linux.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?
>> 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
next prev parent reply other threads:[~2022-08-26 3:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-25 9:23 [RFC PATCH 1/2] mm/demotion: Expose memory type details via sysfs Aneesh Kumar K.V
2022-08-25 9:23 ` [RFC PATCH 2/2] mm/demotion: Expose memory tier " Aneesh Kumar K.V
2022-08-26 4:31 ` Huang, Ying
2022-08-26 1:50 ` [RFC PATCH 1/2] mm/demotion: Expose memory type " Huang, Ying
2022-08-26 2:37 ` Aneesh Kumar K V [this message]
2022-08-26 8:00 ` Wei Xu
2022-08-26 8:05 ` Aneesh Kumar K V
2022-08-26 9:15 ` Wei Xu
2022-08-28 16:20 ` Aneesh Kumar K.V
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e2f20ae9-5761-c170-a4e7-121d6b69ebfb@linux.ibm.com \
--to=aneesh.kumar@linux.ibm.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=bharata@amd.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=dave@stgolabs.net \
--cc=hannes@cmpxchg.org \
--cc=hesham.almatary@huawei.com \
--cc=jvgediya.oss@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=shy828301@gmail.com \
--cc=tim.c.chen@intel.com \
--cc=weixugc@google.com \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.