linux-kernel - Re: [PATCH v5 01/11] mm/mempolicy: implement the sysfs-based weighted

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: <ZZTNpGhj8EmYBB70@memverge.com>
Date: Tue, 2 Jan 2024 21:59:48 -0500
From: Gregory Price <gregory.price@...verge.com>
To: "Huang, Ying" <ying.huang@...el.com>
Cc: Gregory Price <gourry.memverge@...il.com>, linux-mm@...ck.org,
	linux-doc@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
	x86@...nel.org, akpm@...ux-foundation.org, arnd@...db.de,
	tglx@...utronix.de, luto@...nel.org, mingo@...hat.com, bp@...en8.de,
	dave.hansen@...ux.intel.com, hpa@...or.com, mhocko@...nel.org,
	tj@...nel.org, corbet@....net, rakie.kim@...com,
	hyeongtak.ji@...com, honggyu.kim@...com, vtavarespetr@...ron.com,
	peterz@...radead.org, jgroves@...ron.com, ravis.opensrc@...ron.com,
	sthanneeru@...ron.com, emirakhur@...ron.com, Hasan.Maruf@....com,
	seungjun.ha@...sung.com
Subject: Re: [PATCH v5 01/11] mm/mempolicy: implement the sysfs-based
 weighted_interleave interface

On Wed, Jan 03, 2024 at 10:45:53AM +0800, Huang, Ying wrote:
> 
> > The minimum functionality is everything receiving a default weight of 1,
> > such that weighted interleave's behavior defaults to round-robin
> > interleave. This gets the system off the ground.
> 
> I don't think that we need to implement all functionalities now.  But,
> we may need to consider more especially if it may impact the user space
> interface.  The default base weight is something like that.  If we
> change the default base weight from "1" to "16" later, users may be
> surprised.  So, I think it's better to discuss it now.
>

This is a hill I don't particularly care to die on.  I think the weights
are likely to end up being set at boot and rebalanced as (rare) hotplug
events occur.

So if people think the default weight should be 3,16,24 or 123, i don't
think it's going to matter.

> 
> We can use a wrapper function to hide the logic.
>

Done.  I'll push a new set tomorrow.

> > I think it also allows MPOL_F_GWEIGHT to be eliminated.
> 
> Do we need a way to distinguish whether to copy the global weights to
> local weights when the memory policy is created?  That is, when the
> global weights are changed later, will the changes be used?  One
> possible solution is
> 
> - If no weights are specified in set_mempolicy2(), the global weights
>   will be used always.
> 
> - If at least one weight is specified in set_mempolicy2(), it will be
>   used, and the other weights in global weights will be copied to the
>   local weights.  That is, changes to the global weights will not be
>   used.
> 

What's confusing about that is that if a user sets a weight to 0,
they'll get a non-0 weight - always.

In my opinion, if we want to make '0' mean 'use system default', then
it should mean 'ALWAYS use system default for this node'.

"Use the system default at the time the syscall was called, and do not
update to use a new system default if that default is changed" is
confusing.

If you say use a global value, use the global value. Simple.

> --
> Best Regards,
> Huang, Ying