linux-kernel - Re: [PATCH mm-new v2] mm/memcontrol: Flush stats when write stat file

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <19986584-885b-4754-b98c-948e4bf9716b@linux.dev>
Date: Wed, 5 Nov 2025 16:39:18 +0800
From: Lance Yang <lance.yang@...ux.dev>
To: Michal Hocko <mhocko@...e.com>, Leon Huang Fu <leon.huangfu@...pee.com>
Cc: linux-mm@...ck.org, hannes@...xchg.org, roman.gushchin@...ux.dev,
 shakeel.butt@...ux.dev, muchun.song@...ux.dev, akpm@...ux-foundation.org,
 joel.granados@...nel.org, jack@...e.cz, laoar.shao@...il.com,
 mclapinski@...gle.com, kyle.meyer@....com, corbet@....net,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 cgroups@...r.kernel.org
Subject: Re: [PATCH mm-new v2] mm/memcontrol: Flush stats when write stat file



On 2025/11/5 16:19, Michal Hocko wrote:
> On Wed 05-11-25 15:49:16, Leon Huang Fu wrote:
>> diff --git a/mm/memcontrol-v1.c b/mm/memcontrol-v1.c
>> index 6eed14bff742..8cab6b52424b 100644
>> --- a/mm/memcontrol-v1.c
>> +++ b/mm/memcontrol-v1.c
>> @@ -2040,6 +2040,7 @@ struct cftype mem_cgroup_legacy_files[] = {
>>   	{
>>   		.name = "stat",
>>   		.seq_show = memory_stat_show,
>> +		.write_u64 = memory_stat_write,
>>   	},
>>   	{
>>   		.name = "force_empty",
>> @@ -2078,6 +2079,7 @@ struct cftype mem_cgroup_legacy_files[] = {
>>   	{
>>   		.name = "numa_stat",
>>   		.seq_show = memcg_numa_stat_show,
>> +		.write_u64 = memory_stat_write,
>>   	},
> 
> Any reason you are not using .write like others? Also is there any
> reason why a specific value is required. /proc/sys/vm/stat_refresh which does
> something similar ignores the value. Also memcg.peak write handler which
> resets the peak value ignores it. It is true that a specific value
> allows for future extensions but I guess it would be better to be
> consistent with others here.
> 
> One last thing to consider is whether this should follow
> /proc/sys/vm/stat_refresh path and have a single file to flush them all
> or have a per file flushing. I do not have a strong preference but
> considering both are doing the same thing it makes sense to go
> stat_refresh path.

+1

IMHO, a dedicated file like memory.stat_refresh is a much better approach ;)

It's cleaner, simpler to use, and much more intuitive for users.

> 
> In any case, thanks for considering the explicit flushing path which is
> IMHO much better than flushing tunning which would become really hard
> for admins to wrap their heads around. Especially when dealing with
> large fleets of machines to maintain.