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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, Joshua,

Joshua Hahn <joshua.hahnjy@xxxxxxxxx> writes:

> On Fri, 13 Dec 2024 15:19:20 +0900 Hyeonggon Yoo <hyeonggon.yoo@xxxxxx> 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.

>> > +Date:		December 2024
>> > +Contact:	Linux memory management mailing list <linux-mm@xxxxxxxxx>
>> > +Description:	Weight limiting / scaling interface
>> > +
>> > +		The maximum interleave weight for a memory node. When it is
>> > +		updated, any previous changes to interleave weights (i.e. via
>> > +		the nodeN sysfs interfaces) are ignored, and new weights are
>> > +		calculated using ACPI-reported bandwidths and scaled.
>> > +
>> 
>> At first this paragraph sounded like "previously stored weights are 
>> discarded after setting max_node_weight", but I think you mean
>> "User can override the default values, but defaults values are 
>> calculated regardless of the values set by the user". Right?
>
> In the implementation, the first way you interpreted is the correct
> description. That is, if a user manually changes a ndoe weight,
> then updates the max_node_weight, the previous manual change will
> be overwritten by the newly scaled values.
>
> Does this behavior make sense? Perhaps it makes sense to ignore
> user-changed values when doing the re-scaling if a user decides to
> change the max_node_weight value themselves. 
>
> 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.

---
Best Regards,
Huang, Ying




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux