All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Huang, Ying" <ying.huang@intel.com>
To: Aneesh Kumar K V <aneesh.kumar@linux.ibm.com>
Cc: Wei Xu <weixugc@google.com>, Johannes Weiner <hannes@cmpxchg.org>,
	Linux MM <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	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>,
	jvgediya.oss@gmail.com, Bharata B Rao <bharata@amd.com>,
	Greg Thelen <gthelen@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>
Subject: Re: [PATCH v3 updated] mm/demotion: Expose memory tier details via sysfs
Date: Fri, 02 Sep 2022 14:40:30 +0800	[thread overview]
Message-ID: <877d2mz3c1.fsf@yhuang6-desk2.ccr.corp.intel.com> (raw)
In-Reply-To: <2b4ddc45-74ae-27df-d973-6724f61f4e18@linux.ibm.com> (Aneesh Kumar K. V.'s message of "Fri, 2 Sep 2022 12:01:43 +0530")

Aneesh Kumar K V <aneesh.kumar@linux.ibm.com> writes:

> On 9/2/22 11:42 AM, Huang, Ying wrote:
>> Aneesh Kumar K V <aneesh.kumar@linux.ibm.com> writes:
>> 
>>> On 9/2/22 11:10 AM, Huang, Ying wrote:
>>>> Aneesh Kumar K V <aneesh.kumar@linux.ibm.com> writes:
>>>>
>>>>> On 9/2/22 10:39 AM, Wei Xu wrote:
>>>>>> On Thu, Sep 1, 2022 at 5:33 PM Huang, Ying <ying.huang@intel.com> wrote:
>>>>>>>
>>>>>>> Aneesh Kumar K V <aneesh.kumar@linux.ibm.com> writes:
>>>>>>>
>>>>>>>> On 9/1/22 12:31 PM, Huang, Ying wrote:
>>>>>>>>> "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
>>>>>>>>>
>>>>>>>>>> This patch adds /sys/devices/virtual/memory_tiering/ where all memory tier
>>>>>>>>>> related details can be found. All allocated memory tiers will be listed
>>>>>>>>>> there as /sys/devices/virtual/memory_tiering/memory_tierN/
>>>>>>>>>>
>>>>>>>>>> The nodes which are part of a specific memory tier can be listed via
>>>>>>>>>> /sys/devices/virtual/memory_tiering/memory_tierN/nodes
>>>>>>>>>
>>>>>>>>> I think "memory_tier" is a better subsystem/bus name than
>>>>>>>>> memory_tiering.  Because we have a set of memory_tierN devices inside.
>>>>>>>>> "memory_tier" sounds more natural.  I know this is subjective, just my
>>>>>>>>> preference.
>>>>>>>>>
>>>>>
>>>>>
>>>>> I missed replying to this earlier. I will keep memory_tiering as subsystem name in v4 
>>>>> because we would want it to a susbsystem where all memory tiering related details can be found
>>>>> including memory type in the future. This is as per discussion 
>>>>>
>>>>> https://lore.kernel.org/linux-mm/CAAPL-u9TKbHGztAF=r-io3gkX7gorUunS2UfstudCWuihrA=0g@mail.gmail.com
>>>>
>>>> I don't think that it's a good idea to mix 2 types of devices in one
>>>> subsystem (bus).  If my understanding were correct, that breaks the
>>>> driver core convention.
>>>>
>>>
>>> All these are virtual devices .I am not sure i follow what you mean by 2 types of devices.
>>> memory_tiering is a subsystem that represents all the details w.r.t memory tiering. It shows
>>> details of memory tiers and can possibly contain details of different memory types .
>> 
>> IMHO, memory_tier and memory_type are 2 kind of devices.  They have
>> almost totally different attributes (sysfs file).  So, we should create
>> 2 buses for them.  Each has its own attribute group.  "virtual" itself
>> isn't a subsystem.
>
> Considering both the details are related to memory tiering, wouldn't it be much simpler we consolidate
> them within the same subdirectory? I am still not clear why you are suggesting they need to be in different
> sysfs hierarchy.  It doesn't break any driver core convention as you mentioned earlier. 
>
> /sys/devices/virtual/memory_tiering/memory_tierN
> /sys/devices/virtual/memory_tiering/memory_typeN

I think we should add

 /sys/devices/virtual/memory_tier/memory_tierN
 /sys/devices/virtual/memory_type/memory_typeN

I don't think this is complex.  Devices of same bus/subsystem should
have mostly same attributes.  This is my understanding of driver core
convention.

Best Regards,
Huang, Ying

  reply	other threads:[~2022-09-02  6:40 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-30  8:17 [PATCH v3 updated] mm/demotion: Expose memory tier details via sysfs Aneesh Kumar K.V
2022-09-01  7:01 ` Huang, Ying
2022-09-01  8:24   ` Aneesh Kumar K V
2022-09-02  0:29     ` Huang, Ying
2022-09-02  5:09       ` Wei Xu
2022-09-02  5:15         ` Huang, Ying
2022-09-02  5:23         ` Aneesh Kumar K V
2022-09-02  5:40           ` Huang, Ying
2022-09-02  5:46             ` Aneesh Kumar K V
2022-09-02  6:12               ` Huang, Ying
2022-09-02  6:31                 ` Aneesh Kumar K V
2022-09-02  6:40                   ` Huang, Ying [this message]
2022-09-02  6:44                     ` Aneesh Kumar K V
2022-09-02  7:02                       ` Wei Xu
2022-09-02  7:57                         ` Huang, Ying
2022-09-02  8:48                           ` Aneesh Kumar K V
2022-09-02  9:04                             ` Huang, Ying
2022-09-02  9:44                               ` Aneesh Kumar K V
2022-09-05  1:52                                 ` Huang, Ying
2022-09-05  3:50                                   ` Aneesh Kumar K V
2022-09-05  5:13                                     ` Huang, Ying
2022-09-05  5:27                                       ` Aneesh Kumar K V
2022-09-05  5:53                                         ` Huang, Ying
2022-09-05  6:14                                           ` Aneesh Kumar K V
2022-09-05  6:24                                             ` Huang, Ying

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=877d2mz3c1.fsf@yhuang6-desk2.ccr.corp.intel.com \
    --to=ying.huang@intel.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=apopple@nvidia.com \
    --cc=bharata@amd.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=dave@stgolabs.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=gthelen@google.com \
    --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=rafael@kernel.org \
    --cc=shy828301@gmail.com \
    --cc=tim.c.chen@intel.com \
    --cc=weixugc@google.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.