All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Huang, Ying" <ying.huang@intel.com>
To: Wei Xu <weixugc@google.com>
Cc: Aneesh Kumar K V <aneesh.kumar@linux.ibm.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>
Subject: Re: [PATCH v3 updated] mm/demotion: Expose memory tier details via sysfs
Date: Fri, 02 Sep 2022 13:15:04 +0800	[thread overview]
Message-ID: <87k06mz7af.fsf@yhuang6-desk2.ccr.corp.intel.com> (raw)
In-Reply-To: <CAAPL-u8MEs04DkHy6kaS788VjdYZZjAYOgzMnioOzDXbc0ZhhQ@mail.gmail.com> (Wei Xu's message of "Thu, 1 Sep 2022 22:09:13 -0700")

Wei Xu <weixugc@google.com> writes:

> 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.
>> >>
>> >>>
>> >>> A directory hierarchy looks like
>> >>> :/sys/devices/virtual/memory_tiering$ tree memory_tier4/
>> >>> memory_tier4/
>> >>> ├── nodes
>> >>> ├── subsystem -> ../../../../bus/memory_tiering
>> >>> └── uevent
>> >>>
>> >>> All toptier nodes are listed via
>> >>> /sys/devices/virtual/memory_tiering/toptier_nodes
>> >>>
>> >>> :/sys/devices/virtual/memory_tiering$ cat toptier_nodes
>> >>> 0,2
>> >>> :/sys/devices/virtual/memory_tiering$ cat memory_tier4/nodes
>> >>> 0,2
>> >>
>> >> I don't think that it is a good idea to show toptier information in user
>> >> space interface.  Because it is just a in kernel implementation
>> >> details.  Now, we only promote pages from !toptier to toptier.  But
>> >> there may be multiple memory tiers in toptier and !toptier, we may
>> >> change the implementation in the future.  For example, we may promote
>> >> pages from DRAM to HBM in the future.
>> >>
>> >
>> >
>> > In the case you describe above and others, we will always have a list of
>> > NUMA nodes from which memory promotion is not done.
>> > /sys/devices/virtual/memory_tiering/toptier_nodes shows that list.
>>
>> I don't think we will need that interface if we don't restrict promotion
>> in the future.  For example, he can just check the memory tier with
>> smallest number.
>>
>> TBH, I don't know why do we need that interface.  What is it for?  We
>> don't want to expose unnecessary information to restrict our in kernel
>> implementation in the future.
>>
>> So, please remove that interface at least before we discussing it
>> thoroughly.
>
> I have asked for this interface to allow the userspace to query a list
> of top-tier nodes as the targets of userspace-driven promotions.  The
> idea is that demotion can gradually go down tier by tier, but we
> promote hot pages directly to the top-tier and bypass the immediate
> tiers.
>
> Certainly, this can be viewed as a policy choice.

Yes.  It's possible for us to change this in the future.

> Given that now we have a clearly defined memory tier hierarchy in
> sysfs and the toptier_nodes content can be constructed from this
> memory tier hierarchy and other information from the node sysfs
> interfaces, I am fine if we want to remove toptier_nodes and keep the
> current memory tier sysfs interfaces to the minimal.

Thanks!

Best Regards,
Huang, Ying

>> >> Do we need a way to show the default memory tier in sysfs?  That is, the
>> >> memory tier that the DRAM nodes belong to.
>> >>
>> >
>> > I will hold adding that until we have support for modifying memory tier details from
>> > userspace. That is when userspace would want to know about the default memory tier.
>> >
>> > For now, the user interface is a simpler hierarchy of memory tiers, it's associated
>> > nodes and the list of nodes from which promotion is not done.
>>
>> OK.
>>
>> Best Regards,
>> Huang, Ying

  reply	other threads:[~2022-09-02  5:15 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 [this message]
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
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=87k06mz7af.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=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=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.