From: "Zhijian Li (Fujitsu)" <lizhijian@fujitsu.com>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"rafael@kernel.org" <rafael@kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"Yasunori Gotou (Fujitsu)" <y-goto@fujitsu.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jagdish Gediya <jvgediya@linux.ibm.com>
Subject: Re: [PATCH RFC 1/4] drivers/base/node: Add demotion_nodes sys infterface
Date: Fri, 2 Feb 2024 07:43:11 +0000 [thread overview]
Message-ID: <797f9b10-5626-4511-af6f-6b90cd5c884c@fujitsu.com> (raw)
In-Reply-To: <cc125e55-890e-4de8-876a-30d88e8438b0@fujitsu.com>
On 31/01/2024 11:17, Li Zhijian wrote:
>>> node[0].preferred = 2
>>> node[0].demotion_targets = 2-5
>>> node[1].preferred = 5
>>> node[1].demotion_targets = 2-5
>>> node[2].preferred = 4
>>> node[2].demotion_targets = 3-4
>>> node[3].preferred = <empty>
>>> node[3].demotion_targets = <empty>
>>> node[4].preferred = <empty>
>>> node[4].demotion_targets = <empty>
>>> node[5].preferred = 3
>>> node[5].demotion_targets = 3-4
>>> But
>>> this demotion path is not explicitly known to administrator. And with
>>> the
>>> feedback from our customers, they also think it is helpful to know demotion
>>> path built by kernel to understand the demotion behaviors.
>>>
>>> So i think we should have 2 new interfaces for each node:
>>>
>>> /sys/devices/system/node/nodeN/demotion_allowed_nodes
>>> /sys/devices/system/node/nodeN/demotion_preferred_nodes
>>>
>>> I value your opinion, and I'd like to know what you think about...
>>
>> Per my understanding, we will not expose everything inside kernel to
>> user space. For page placement in a tiered memory system, demotion is
>> just a part of the story. For example, if the DRAM of a system becomes
>> full, new page allocation will fall back to the CXL memory. Have we
>> exposed the default page allocation fallback order to user space?
Back to our initial requirement:
When demotion is enabled, what's the demotion path, especially the preferred node?
are they consistent with administrator's expectations?"
It seems there is no a direct answer. But actually, kernel have already known
this information, IMHO, exposing them to users is not a bad choice.
This information is able to help them adjust/tune the machine before really
deploy their workloads.
If the sysfs approach isn't better enough, is it possible to have another more
user-friendly way to convey this information? like the allocation fallback order does,
simply print them to dmesg?
Thanks
Zhijian
>
> Good question, I have no answer yet, but I think we can get the fallback order
> from the dmesg now.
>
> The further action for us is that we will also try improve the use space tool,
> such as numactl to show the demotion path with the help of this exposed information.
next prev parent reply other threads:[~2024-02-02 7:43 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-02 2:56 Subject: [PATCH RFC 0/4] Demotion Profiling Improvements Li Zhijian
2023-11-02 2:56 ` [PATCH RFC 1/4] drivers/base/node: Add demotion_nodes sys infterface Li Zhijian
2023-11-02 3:17 ` Huang, Ying
2023-11-02 3:39 ` Zhijian Li (Fujitsu)
2023-11-02 5:18 ` Huang, Ying
2023-11-02 5:54 ` Zhijian Li (Fujitsu)
2023-11-02 5:58 ` Huang, Ying
2023-11-03 3:05 ` Zhijian Li (Fujitsu)
2024-01-30 8:53 ` Li Zhijian
2024-01-31 1:13 ` Huang, Ying
2024-01-31 3:18 ` Zhijian Li (Fujitsu)
2024-02-02 7:43 ` Zhijian Li (Fujitsu) [this message]
2024-02-02 8:19 ` Huang, Ying
2024-02-05 7:31 ` Zhijian Li (Fujitsu)
2024-01-31 6:23 ` Yasunori Gotou (Fujitsu)
2024-01-31 6:52 ` Huang, Ying
2023-11-02 2:56 ` [PATCH RFC 2/4] mm/vmstat: Move pgdemote_* to per-node stats Li Zhijian
2023-11-02 4:56 ` Huang, Ying
2023-11-02 5:43 ` Huang, Ying
2023-11-02 5:57 ` Zhijian Li (Fujitsu)
2023-11-02 2:56 ` [PATCH RFC 3/4] mm/vmstat: rename pgdemote_* to pgdemote_dst_* and add pgdemote_src_* Li Zhijian
2023-11-02 5:45 ` Huang, Ying
2023-11-02 6:34 ` Zhijian Li (Fujitsu)
2023-11-02 6:56 ` Huang, Ying
2023-11-02 7:38 ` Yasunori Gotou (Fujitsu)
2023-11-02 7:46 ` Huang, Ying
2023-11-02 9:45 ` Yasunori Gotou (Fujitsu)
2023-11-03 6:14 ` Huang, Ying
2023-11-06 5:02 ` Yasunori Gotou (Fujitsu)
2023-11-02 2:56 ` [PATCH RFC 4/4] drivers/base/node: add demote_src and demote_dst to numastat Li Zhijian
2023-11-02 5:40 ` Greg Kroah-Hartman
2023-11-02 8:15 ` Zhijian Li (Fujitsu)
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=797f9b10-5626-4511-af6f-6b90cd5c884c@fujitsu.com \
--to=lizhijian@fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=jvgediya@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rafael@kernel.org \
--cc=y-goto@fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox