Re: [PATCH v2 3/3] Docs/admin-guide/mm/damon/usage: document the temporal tuner's quota limit

[SJ Park]

On Sun, 20 Sep 2026 11:31:11 +0900 Donggeun Yoo <donggeunyoo.kernel@xxxxxxxxx> wrote:

> The temporal goal tuner converts the size quota into basis points in an
> unsigned long, so a quotas/bytes above ULONG_MAX / 10000 does not fit,
> and is handled as if no size quota were set.  On 32-bit that is 429496
> bytes, well below the "echo $((1024*1024*1024)) > quotas/bytes" this
> document instructs.  addr_unit does not raise the limit, though a larger
> unit does make it harder to reach.
> 
> Note both in the goal_tuner description.
> 
> Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@xxxxxxxxx>
> ---
>  Documentation/admin-guide/mm/damon/usage.rst | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
> index ba47255448564..ea7443b307826 100644
> --- a/Documentation/admin-guide/mm/damon/usage.rst
> +++ b/Documentation/admin-guide/mm/damon/usage.rst
> @@ -455,6 +455,13 @@ the background design of the feature and the name of the selectable algorithms.
>  Refer to :ref:`goals directory <sysfs_schemes_quota_goals>` for the goals
>  setup.
>  
> +The ``temporal`` algorithm converts the size quota into basis points, so it
> +cannot represent a ``bytes`` value larger than 429496 on 32-bit kernels, or
> +1844674407370955 on 64-bit ones.

This feels like too much implementation details.

> Larger values are handled as if no size
> +quota were set.

I don't get what this means.

> :ref:`addr_unit <damon_design_addr_unit>` does not raise the
> +limit, but it does make the limit harder to reach: with a larger unit, the
> +same amount of memory is written to ``bytes`` as a smaller number.

I suggested it might make sense to document this problem, but now I doubt if
this is really helpful for users.  Given the fact that the issue can happen on
only untested setups, I now think this documentation change is better not to be
made.  Correct me if I'm wrong.  If I'm not incorrect, could we drop this
patch?


Thanks,
SJ

[...]