[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d2b76402-7e1a-4b2d-892a-2e8ffe1a37a9@linux.alibaba.com>
Date: Wed, 4 Jun 2025 22:16:18 +0800
From: Baolin Wang <baolin.wang@...ux.alibaba.com>
To: Vlastimil Babka <vbabka@...e.cz>, Shakeel Butt <shakeel.butt@...ux.dev>,
Michal Hocko <mhocko@...e.com>
Cc: 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/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
Powered by blists - more mailing lists