From: Gregory Price <gourry@gourry.net>
To: "Huang, Ying" <ying.huang@linux.alibaba.com>
Cc: "Joshua Hahn" <joshua.hahnjy@gmail.com>,
hyeonggon.yoo@sk.com, "gourry@gourry.net" <gourry@gourry.net>,
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: Sat, 21 Dec 2024 09:58:08 -0500 [thread overview]
Message-ID: <Z2bXgMw5WPCqwGSk@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <87jzbtr315.fsf@DESKTOP-5N7EMDA>
On Sat, Dec 21, 2024 at 01:57:58PM +0800, Huang, Ying wrote:
> Hi, Joshua,
>
> Joshua Hahn <joshua.hahnjy@gmail.com> writes:
>
> > On Fri, 13 Dec 2024 15:19:20 +0900 Hyeonggon Yoo <hyeonggon.yoo@sk.com> wrote:
> >
> >> On 2024-12-11 06:54 AM, Joshua Hahn wrote:
>
> [snip]
>
> >
> > [-----8<-----]
> >
> >> > +What: /sys/kernel/mm/mempolicy/weighted_interleave/max_node_weight
>
> I don't think that we need a new knob for this. Just use a reasonable
> default value, for example, 32 or 16. If it turns out that a knob will
> be really helpful, we can add it at that time. For now, I don't think
> the requirements are clear. And, this is a new ABI and we need to
> maintain it almost for ever. We must be careful about new knob.
>
This is fair. We spent a good amount of time modeling the best
effective maximum weight and basically came to the conclusion that 32
has a good balance of minimizing error and being somewhat aggressive.
Ripping out the sysfs is easy enough.
> >
> > Regardless of what implementation makes sense, I can re-write the
> > description so that there is no ambiguity when it comes to the
> > expected behavior of the code. Thank you for pointing this out!
>
> I don't think that it's a good idea to override the user supplied
> configuration values. User configurations always have higher priority
> than system default configurations. IIUC, this is the general rule of
> Linux kernel user space interface.
>
We discussed this and decided it was confusing no matter what we did.
If new data comes in (CDAT data from a hotplug event), then the weights
are now wrong for the new global state - regardless of whether the user
set a weight manually or not. This also allowed us to simplify the
implementation a bit.
But if generally we need to preserve user settings, then I think the
best we can do to provide a sane system is ignore the user setting when
re-weighting on a hotplug event.
e.g. user has not set a value
default_values [5,2,-] <- 1 node not set, expected to be hotplugged
user_values [-,-,-] <- user has not set values
effective [5,2,-]
hotplug event
default_values [2,1,1] - reweight has occurred
user_values [-,-,-]
effective [2,1,1]
e.g. user has set a value
default_values [5,2,-] <- 1 node not set, expected to be hotplugged
user_values [4,-,-] <- user has only set one value
effective [4,2,-]
hotplug event
default_values [2,1,1] - reweight has occurred
user_values [4,-,-]
effective [4,1,1]
So default values get updated, but user values get left alone.
If that's sane we'll fix it up.
> ---
> Best Regards,
> Huang, Ying
next prev parent reply other threads:[~2024-12-21 14:58 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 [this message]
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
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=Z2bXgMw5WPCqwGSk@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.