What:		/sys/kernel/mm/mempolicy/weighted_interleave/
Date:		January 2024
Contact:	Linux memory management mailing list <linux-mm@kvack.org>
Description:	Configuration Interface for the Weighted Interleave policy

What:		/sys/kernel/mm/mempolicy/weighted_interleave/nodeN
Date:		January 2024
Contact:	Linux memory management mailing list <linux-mm@kvack.org>
Description:	Weight configuration interface for nodeN

		The interleave weight for a memory node (N). These weights are
		utilized by tasks which have set their mempolicy to
		MPOL_WEIGHTED_INTERLEAVE.

		These weights only affect new allocations, and changes at runtime
		will not cause migrations on already allocated pages.

		The minimum weight for a node is always 1.

		Minimum weight: 1
		Maximum weight: 255

		Writing invalid values (i.e. any values not in [1,255],
		empty string, ...) will return -EINVAL.

		Changing the weight to a valid value will automatically
		switch the system to manual mode as well.

What:		/sys/kernel/mm/mempolicy/weighted_interleave/auto
Date:		May 2025
Contact:	Linux memory management mailing list <linux-mm@kvack.org>
Description:	Auto-weighting configuration interface

		Configuration mode for weighted interleave. 'true' indicates
		that the system is in auto mode, and a 'false' indicates that
		the system is in manual mode.

		In auto mode, all node weights are re-calculated and overwritten
		(visible via the nodeN interfaces) whenever new bandwidth data
		is made available during either boot or hotplug events.

		In manual mode, node weights can only be updated by the user.
		Note that nodes that are onlined with previously set weights
		will reuse those weights. If they were not previously set or
		are onlined with missing bandwidth data, the weights will use
		a default weight of 1.

		Writing any true value string (e.g. Y or 1) will enable auto
		mode, while writing any false value string (e.g. N or 0) will
		enable manual mode. All other strings are ignored and will
		return -EINVAL.

		Writing a new weight to a node directly via the nodeN interface
		will also automatically switch the system to manual mode.
 instead of GMII</title>
<updated>2020-02-24T23:12:10+00:00</updated>
<author>
<name>Vladimir Oltean</name>
<email>vladimir.oltean@nxp.com</email>
</author>
<published>2020-02-24T12:15:33+00:00</published>
<link rel='alternate' type='text/html' href='http://git.armlinux.org.uk/cgit/linux-net-next.git/commit/?id=28a134f5a0553110c623c31ceb653a21fbe92be7'/>
<id>28a134f5a0553110c623c31ceb653a21fbe92be7</id>
<content type='text'>
phy-mode = "gmii" is confusing because it may mean that the port
supports the 8-bit-wide parallel data interface pinout, which it
doesn't.

It may also be confusing because one of the "gmii" internal ports is
actually overclocked to run at 2.5Gbps (even though, yes, as far as the
switch MAC is concerned, it still thinks it's gigabit).

So use the phy-mode = "internal" property to describe the internal ports
inside the NXP LS1028A chip (the ones facing the ENETC). The change
should be fine, because the device tree bindings document is yet to be
introduced, and there are no stable DT blobs in use.

Signed-off-by: Vladimir Oltean &lt;vladimir.oltean@nxp.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Tested-by: Michael Walle &lt;michael@walle.cc&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
phy-mode = "gmii" is confusing because it may mean that the port
supports the 8-bit-wide parallel data interface pinout, which it
doesn't.

It may also be confusing because one of the "gmii" internal ports is
actually overclocked to run at 2.5Gbps (even though, yes, as far as the
switch MAC is concerned, it still thinks it's gigabit).

So use the phy-mode = "internal" property to describe the internal ports
inside the NXP LS1028A chip (the ones facing the ENETC). The change
should be fine, because the device tree bindings document is yet to be
introduced, and there are no stable DT blobs in use.

Signed-off-by: Vladimir Oltean &lt;vladimir.oltean@nxp.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Tested-by: Michael Walle &lt;michael@walle.cc&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>