Update documentation for memory.max to clarify that the reported value
is in multiples of the system page_size. The following example
demonstrates this behavior:

  # cd /sys/fs/cgroup/
  # cat cgroup.subtree_control
  cpu io memory pids
  # mkdir mem
  # cd mem
  # echo 8000000 > memory.max
  # cat memory.max
  7995392

  # getconf PAGESIZE
  65536

  # echo $((8000000/65536*65536))
  7995392

Signed-off-by: Vishal Chourasia <vishalc@linux.ibm.com>
---
 Documentation/admin-guide/cgroup-v2.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index 1a16ce68a4d7..577d05c03ffa 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -1316,6 +1316,9 @@ PAGE_SIZE multiple when read back.
 	Caller could retry them differently, return into userspace
 	as -ENOMEM or silently ignore in cases like disk readahead.
 
+        Note that the value set for memory.max is reported in units
+        corresponding to the system's page size.
+
   memory.reclaim
 	A write-only nested-keyed file which exists for all cgroups.
 
-- 
2.49.0

Hello.

On Thu, Apr 10, 2025 at 07:04:40PM +0530, Vishal Chourasia <vishalc@linux.ibm.com> wrote:
> Update documentation for memory.max to clarify that the reported value
> is in multiples of the system page_size. The following example
> demonstrates this behavior:

This applies to any of page_counter-based attribute, not only
memory.max.

> --- a/Documentation/admin-guide/cgroup-v2.rst
> +++ b/Documentation/admin-guide/cgroup-v2.rst
> @@ -1316,6 +1316,9 @@ PAGE_SIZE multiple when read back.
>  	Caller could retry them differently, return into userspace
>  	as -ENOMEM or silently ignore in cases like disk readahead.
>  
> +        Note that the value set for memory.max is reported in units
> +        corresponding to the system's page size.
> +

There seems to be mismatch in whitespace to surrounding text.

Also the wording would be more precise if it referred to 'multiples',
not 'units' (units are simply bytes).

Michal

On Thu, Apr 10, 2025 at 03:47:06PM +0200, Michal Koutný wrote:
> Hello.
> 
> On Thu, Apr 10, 2025 at 07:04:40PM +0530, Vishal Chourasia <vishalc@linux.ibm.com> wrote:
> > Update documentation for memory.max to clarify that the reported value
> > is in multiples of the system page_size. The following example
> > demonstrates this behavior:
> 
> This applies to any of page_counter-based attribute, not only
> memory.max.
> 
Yes. This is already documented, and I missed it.

From Documentation/admin-api/cgroup-v2.rst:
...
Memory Interface Files
~~~~~~~~~~~~~~~~~~~~~~

All memory amounts are in bytes.  If a value which is not aligned to
PAGE_SIZE is written, the value may be rounded up to the closest
PAGE_SIZE multiple when read back.
...
> > --- a/Documentation/admin-guide/cgroup-v2.rst
> > +++ b/Documentation/admin-guide/cgroup-v2.rst
> > @@ -1316,6 +1316,9 @@ PAGE_SIZE multiple when read back.
> >  	Caller could retry them differently, return into userspace
> >  	as -ENOMEM or silently ignore in cases like disk readahead.
> >  
> > +        Note that the value set for memory.max is reported in units
> > +        corresponding to the system's page size.
> > +
> 
> There seems to be mismatch in whitespace to surrounding text.
> 
> Also the wording would be more precise if it referred to 'multiples',
> not 'units' (units are simply bytes).
> 
> Michal
>
Got it. But, it seems this patch is redundant. So, I won't be sending
another version.

Thanks,
Vishal