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] [day] [month] [year] [list]

Message-ID: <Z2hEXttgNMjAo8-q@gourry-fedora-PF4VCD3F>
Date: Sun, 22 Dec 2024 11:54:54 -0500
From: Gregory Price <gourry@...rry.net>
To: "Huang, Ying" <ying.huang@...ux.alibaba.com>
Cc: Gregory Price <gourry@...rry.net>,
	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

On Sun, Dec 22, 2024 at 04:29:30PM +0800, Huang, Ying wrote:
> Gregory Price <gourry@...rry.net> writes:
> 
> > On Sat, Dec 21, 2024 at 01:57:58PM +0800, Huang, Ying wrote:
> 
> 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.

This is probably the actual way to go.  

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

We decided when implementing weights that 0 was a special value that
reverts to the system default:

  Writing an empty string or `0` will reset the weight to the
  system default. The system default may be set by the kernel
  or drivers at boot or during hotplug events.

I'm ok pulling the default weights in collectively once the first one is
written, but 0 is an invalid value which causes issues.

We went through that when we initially implemented the feature w/ task-local
weights and why the help function overrides it to 1 if it's ever seen.

We'll revert back to our initial implementation w/ default_iw_table and
iw_table - where iw_table contains user-defined weights.  Writing a 0 to
iw_table[N] will allow get_il_weight() to retrieve default_iw_table[N]
as the docs imply it should.

~Gregory