linux-kernel - Re: [External Mail] [RFC PATCH] mm/mempolicy: Weighted interleave auto-tuning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87ldw8i0id.fsf@DESKTOP-5N7EMDA>
Date: Sun, 22 Dec 2024 16:29:30 +0800
From: "Huang, Ying" <ying.huang@...ux.alibaba.com>
To: Gregory Price <gourry@...rry.net>
Cc: Joshua Hahn <joshua.hahnjy@...il.com>,  hyeonggon.yoo@...com,
  kernel_team@...ynix.com,  "rafael@...nel.org" <rafael@...nel.org>,
  "lenb@...nel.org" <lenb@...nel.org>,  "gregkh@...uxfoundation.org"
 <gregkh@...uxfoundation.org>,  "akpm@...ux-foundation.org"
 <akpm@...ux-foundation.org>,  김홍규(KIM HONGGYU)
 System SW
 <honggyu.kim@...com>,  김락기(KIM RAKIE) System SW
 <rakie.kim@...com>,
  "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
  "Jonathan.Cameron@...wei.com" <Jonathan.Cameron@...wei.com>,
  "dave.jiang@...el.com" <dave.jiang@...el.com>,  "horen.chuang@...ux.dev"
 <horen.chuang@...ux.dev>,  "hannes@...xchg.org" <hannes@...xchg.org>,
  "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
  "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
  "linux-mm@...ck.org" <linux-mm@...ck.org>,  "kernel-team@...a.com"
 <kernel-team@...a.com>
Subject: Re: [External Mail] [RFC PATCH] mm/mempolicy: Weighted interleave
 auto-tuning

Gregory Price <gourry@...rry.net> writes:

> On Sat, Dec 21, 2024 at 01:57:58PM +0800, Huang, Ying wrote:
>> Hi, Joshua,
>> 
>> Joshua Hahn <joshua.hahnjy@...il.com> writes:
>> 
>> > On Fri, 13 Dec 2024 15:19:20 +0900 Hyeonggon Yoo <hyeonggon.yoo@...com> wrote:
>> >
>> >> On 2024-12-11 06:54 AM, Joshua Hahn wrote:
>>

[snip]

>
>> >
>> > 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]

Another choice is that if the user set a value, he/she set all values
effectively.  Even if he/she doesn't set the other values, he/she thinks
that the other values are good, and more importantly, the ratio is good.
If so,

default_values [5,2,-] <- 1 node not set, expected to be hotplugged
user_values    [4,2,0] <- user has only set one value, not populated nodes have value 0
effective      [4,2,0]

hotplug event
default_values [2,1,1] - reweight has occurred
user_values    [4,2,0]
effective      [4,2,0]

In this way, 0 becomes a valid value too.

What do you think about this?

> So default values get updated, but user values get left alone.
>
> If that's sane we'll fix it up.

---
Best Regards,
Huang, Ying