From: Gregory Price <gourry@gourry.net>
To: "Huang, Ying" <ying.huang@linux.alibaba.com>
Cc: "Joshua Hahn" <joshua.hahnjy@gmail.com>,
"Gregory Price" <gourry@gourry.net>,
hyeonggon.yoo@sk.com, kernel_team@skhynix.com,
"rafael@kernel.org" <rafael@kernel.org>,
"lenb@kernel.org" <lenb@kernel.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"김홍규(KIM HONGGYU) System SW" <honggyu.kim@sk.com>,
"김락기(KIM RAKIE) System SW" <rakie.kim@sk.com>,
"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
"Jonathan.Cameron@huawei.com" <Jonathan.Cameron@huawei.com>,
"dave.jiang@intel.com" <dave.jiang@intel.com>,
"horen.chuang@linux.dev" <horen.chuang@linux.dev>,
"hannes@cmpxchg.org" <hannes@cmpxchg.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"kernel-team@meta.com" <kernel-team@meta.com>
Subject: Re: [External Mail] [RFC PATCH] mm/mempolicy: Weighted interleave auto-tuning
Date: Thu, 26 Dec 2024 11:13:21 -0700 [thread overview]
Message-ID: <Z22cwZycFV47wOfX@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <874j2rp6or.fsf@DESKTOP-5N7EMDA>
On Thu, Dec 26, 2024 at 09:35:32AM +0800, Huang, Ying wrote:
> > Having two files for each node (nodeN, defaultN) seems a bit too
> > cluttered for the user perspective. Making the nodeN interfaces serve
> > multiple purposes (i.e. echo -1 into the nodes will output the default
> > value for that node) also seems a bit too complicated as well, in my
> > opinion. Maybe having a file 'weight_tables' that contains a table of
> > default/user/effective weights (as have been used in these conversations)
> > might be useful for the user? (Or maybe just the defaults)
> >
> > Then a workflow for the user may be as such:
> >
> > $ cat /sys/kernel/mm/mempolicy/weighted_interleave/weight_tables
> > default vales: [4,7,2]
> > user values: [-,-,-]
> > effective: [4,7,2]
>
> AFAIK, this breaks the sysfs attribute format rule as follows.
>
> https://docs.kernel.org/filesystems/sysfs.html#attributes
>
> It's hard to use array sysfs attribute here too. Because the node ID
> may be non-consecutive. This makes it hard to read.
>
Would generally agree. I think essentially a
use_defaults => (0 | 1)
interface is probably the best we can do.
Setting any node changes use_defaults from 1 => 0
echoing 1 into use_default clears user_values
This still allows 0 to be a manual "reset specific node to default"
mechanism for a specific node, and gives us a clean override.
The only question is a matter of hotplug behavior
nodes_online: 0,1
default_values: [5,3]
user_values : [-,-]
event: node1 is taken offline
default_values: [5,3] <-- nothing happens
event: node1 comes back online with different bandwidth attribute
default_values: [6,5] <-- reweight as occured silently
event: user sets a custom value (node1 <= 2)
default_values: [6,5]
user_values: [6,2] <= note, *no reduction*
event: node1 is taken offline
default_values: [6,5]
user_values: [6,2] <= value still present but not used
event: node1 comes back online with different bandwidth attribute
default_values: [5,3] <-- default reweight has occurred silently
user_values : [6,2] <-- user responsible for triggering re-weight
The user has the option of
echo 1 > /sys/.../weghted_interleave/user_defaults
result
default_values: [5,3]
user_values : [-,-]
or
echo 0 > /sys/.../weighted_interleave/node1
result
default_values: [5,3]
user_values : [6,3] <= only node1 is updated, no re-weight
Basically, if the user ever sets any value, we never automatically pull
new values in, and the admin is responsible for triggering a re-weight
(use_default) or manually reweighting *all* nodes - because changing
values implies a change in the bandwidth distribution anyway.
I think this makes the most sense.
~Gregory
next prev parent reply other threads:[~2024-12-26 18:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-10 21:54 [RFC PATCH] mm/mempolicy: Weighted interleave auto-tuning Joshua Hahn
2024-12-11 11:39 ` kernel test robot
2024-12-13 6:19 ` [External Mail] " Hyeonggon Yoo
2024-12-13 16:28 ` Gregory Price
2024-12-13 19:57 ` Joshua Hahn
2024-12-16 7:53 ` Hyeonggon Yoo
2024-12-16 15:46 ` Joshua Hahn
2024-12-21 5:57 ` Huang, Ying
2024-12-21 14:58 ` Gregory Price
2024-12-22 8:29 ` Huang, Ying
2024-12-22 16:54 ` Gregory Price
2024-12-25 0:25 ` Huang, Ying
2024-12-25 9:30 ` Joshua Hahn
2024-12-26 1:35 ` Huang, Ying
2024-12-26 18:13 ` Gregory Price [this message]
2024-12-27 1:59 ` Huang, Ying
2024-12-27 15:35 ` Gregory Price
2024-12-30 6:48 ` Huang, Ying
2025-01-08 1:19 ` [External Mail] " Hyeonggon Yoo
2025-01-08 16:56 ` Joshua Hahn
2025-01-09 15:56 ` Gregory Price
2025-01-09 17:18 ` Joshua Hahn
2025-01-09 19:10 ` Joshua Hahn
2025-01-21 11:01 ` 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=Z22cwZycFV47wOfX@gourry-fedora-PF4VCD3F \
--to=gourry@gourry.net \
--cc=Jonathan.Cameron@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=honggyu.kim@sk.com \
--cc=horen.chuang@linux.dev \
--cc=hyeonggon.yoo@sk.com \
--cc=joshua.hahnjy@gmail.com \
--cc=kernel-team@meta.com \
--cc=kernel_team@skhynix.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rafael@kernel.org \
--cc=rakie.kim@sk.com \
--cc=ying.huang@linux.alibaba.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.