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] [day] [month] [year] [list]
Message-ID: <4e96a241-a996-4289-9ac5-dc1ff65cbff8@fujitsu.com>
Date: Thu, 16 Jan 2025 05:50:54 +0000
From: "Zhijian Li (Fujitsu)" <lizhijian@...itsu.com>
To: Jonathan Corbet <corbet@....net>, "linux-doc@...r.kernel.org"
	<linux-doc@...r.kernel.org>
CC: Tejun Heo <tj@...nel.org>, Johannes Weiner <hannes@...xchg.org>,
	"mkoutny@...e.com" <mkoutny@...e.com>, "cgroups@...r.kernel.org"
	<cgroups@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Waiman Long <llong@...hat.com>
Subject: Re: [PATCH v2] Documentation/cgroup-v2: Update
 memory.{stat,numa_stat} description to reflect possible units

Hi Jonathan,


On 14/01/2025 01:49, Jonathan Corbet wrote:
> Li Zhijian <lizhijian@...itsu.com> writes:
> 
>> The description of the memory.{stat,numa_stat} file has been updated to
>> clarify that the output values can be in bytes or pages.
>> This change ensures that users are aware that the unit of measurement for
>> memory values can vary and should be verified by consulting the memory.stat
>>
>> It's known that
>> workingset_*, pg* are counted in pages
>>
>> Signed-off-by: Li Zhijian <lizhijian@...itsu.com>a
>> ---
>> V2: updated the document as suggestion from Michal
>>      updated subject and commit log
>> ---
>>   Documentation/admin-guide/cgroup-v2.rst | 9 +++++----
>>   1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
>> index 315ede811c9d..0a43be0c32d1 100644
>> --- a/Documentation/admin-guide/cgroup-v2.rst
>> +++ b/Documentation/admin-guide/cgroup-v2.rst
>> @@ -1427,7 +1427,7 @@ The following nested keys are defined.
>>   	types of memory, type-specific details, and other information
>>   	on the state and past events of the memory management system.
>>   
>> -	All memory amounts are in bytes.
>> +	All memory amounts are in bytes unless said otherwise.
>>   
>>   	The entries are ordered to be human readable, and new entries
>>   	can show up in the middle. Don't rely on items remaining in a
>> @@ -1673,11 +1673,12 @@ The following nested keys are defined.
>>   	application performance by combining this information with the
>>   	application's CPU allocation.
>>   
>> -	All memory amounts are in bytes.
>> -
>>   	The output format of memory.numa_stat is::
>>   
>> -	  type N0=<bytes in node 0> N1=<bytes in node 1> ...
>> +	  type N0=<value for node 0> N1=<value for node 1> ...
>> +
>> +        The 'value' can be in bytes or pages, depending on the specific
>> +        type of memory. To determine the unit, refer to the memory.stat.
> 
> This seems like useful information - but can we really not give better
> guidance to our readers on how to interpret this value?  What in "the
> memory.stat" will tell them which units are in use?

Let me quote a piece of the numa.stat:

In pages:
>          pgdemote_khugepaged                                                   
>                Number of pages demoted by khugepaged.

In bytes:
>          file                                                                  
>                Amount of memory used to cache filesystem data,                 
>                including tmpfs and shared memory. 

Prior to this reference to `memory.stat`, the previous `memory.numa_stat` also
relied on `memory.stat` to determine which entries were present.
Therefore, adding this current reference to `memory.stat` does not introduce
additional complexity.

1680         The 'value' can be in bytes or pages, depending on the specific
1681         type of memory. To determine the unit, refer to the memory.stat.
1682
1683         The entries are ordered to be human readable, and new entries
1684         can show up in the middle. Don't rely on items remaining in a
1685         fixed position; use the keys to look up specific values!
1686
1687         The entries can refer to the memory.stat.   <<< the original reference


> (Even better, could we fix the code to always return the same units
> without breaking something somewhere?)


Of course, I am not opposed to having all entries use the same unit.
At a glance, there are quite a few entries within `memory.stat` that are
actually measured in pages. Do we truly request to this significant modification?


Thanks
Zhijian

> 
> Thanks,
> 
> jon

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ