linux-kernel - Re: [PATCH] mm: fix the inaccurate memory statistics issue for users

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <985a92d4-e0d4-4164-88eb-dc7931e2c40c@linux.alibaba.com>
Date: Thu, 5 Jun 2025 08:48:07 +0800
From: Baolin Wang <baolin.wang@...ux.alibaba.com>
To: Shakeel Butt <shakeel.butt@...ux.dev>
Cc: Vlastimil Babka <vbabka@...e.cz>, Michal Hocko <mhocko@...e.com>,
 Andrew Morton <akpm@...ux-foundation.org>, david@...hat.com,
 lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com, rppt@...nel.org,
 surenb@...gle.com, donettom@...ux.ibm.com, aboorvad@...ux.ibm.com,
 sj@...nel.org, linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: fix the inaccurate memory statistics issue for users



On 2025/6/5 00:54, Shakeel Butt wrote:
> On Wed, Jun 04, 2025 at 10:16:18PM +0800, Baolin Wang wrote:
>>
>>
>> On 2025/6/4 21:46, Vlastimil Babka wrote:
>>> On 6/4/25 14:46, Baolin Wang wrote:
>>>>> Baolin, please run stress-ng command that stresses minor anon page
>>>>> faults in multiple threads and then run multiple bash scripts which cat
>>>>> /proc/pidof(stress-ng)/status. That should be how much the stress-ng
>>>>> process is impacted by the parallel status readers versus without them.
>>>>
>>>> Sure. Thanks Shakeel. I run the stress-ng with the 'stress-ng --fault 32
>>>> --perf -t 1m' command, while simultaneously running the following
>>>> scripts to read the /proc/pidof(stress-ng)/status for each thread.
>>>
>>> How many of those scripts?
>>
>> 1 script, but will start 32 threads to read each stress-ng thread's status
>> interface.
>>
>>>>    From the following data, I did not observe any obvious impact of this
>>>> patch on the stress-ng tests when repeatedly reading the
>>>> /proc/pidof(stress-ng)/status.
>>>>
>>>> w/o patch
>>>> stress-ng: info:  [6891]          3,993,235,331,584 CPU Cycles
>>>>             59.767 B/sec
>>>> stress-ng: info:  [6891]          1,472,101,565,760 Instructions
>>>>             22.033 B/sec (0.369 instr. per cycle)
>>>> stress-ng: info:  [6891]                 36,287,456 Page Faults Total
>>>>              0.543 M/sec
>>>> stress-ng: info:  [6891]                 36,287,456 Page Faults Minor
>>>>              0.543 M/sec
>>>>
>>>> w/ patch
>>>> stress-ng: info:  [6872]          4,018,592,975,968 CPU Cycles
>>>>             60.177 B/sec
>>>> stress-ng: info:  [6872]          1,484,856,150,976 Instructions
>>>>             22.235 B/sec (0.369 instr. per cycle)
>>>> stress-ng: info:  [6872]                 36,547,456 Page Faults Total
>>>>              0.547 M/sec
>>>> stress-ng: info:  [6872]                 36,547,456 Page Faults Minor
>>>>              0.547 M/sec
>>>>
>>>> =========================
>>>> #!/bin/bash
>>>>
>>>> # Get the PIDs of stress-ng processes
>>>> PIDS=$(pgrep stress-ng)
>>>>
>>>> # Loop through each PID and monitor /proc/[pid]/status
>>>> for PID in $PIDS; do
>>>>        while true; do
>>>>            cat /proc/$PID/status
>>>> 	usleep 100000
>>>
>>> Hm but this limits the reading to 10 per second? If we want to simulate an
>>> adversary process, it should be without the sleeps I think?
>>
>> OK. I drop the usleep, and I still can not see obvious impact.
>>
>> w/o patch:
>> stress-ng: info:  [6848]          4,399,219,085,152 CPU Cycles
>> 67.327 B/sec
>> stress-ng: info:  [6848]          1,616,524,844,832 Instructions
>> 24.740 B/sec (0.367 instr. per cycle)
>> stress-ng: info:  [6848]                 39,529,792 Page Faults Total
>> 0.605 M/sec
>> stress-ng: info:  [6848]                 39,529,792 Page Faults Minor
>> 0.605 M/sec
>>
>> w/patch:
>> stress-ng: info:  [2485]          4,462,440,381,856 CPU Cycles
>> 68.382 B/sec
>> stress-ng: info:  [2485]          1,615,101,503,296 Instructions
>> 24.750 B/sec (0.362 instr. per cycle)
>> stress-ng: info:  [2485]                 39,439,232 Page Faults Total
>> 0.604 M/sec
>> stress-ng: info:  [2485]                 39,439,232 Page Faults Minor
>> 0.604 M/sec
> 
> Is the above with 32 non-sleeping parallel reader scripts?

Yes.