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: <1aa7c368-c37f-4b00-876c-dcf51a523c42@suse.cz>
Date: Wed, 4 Jun 2025 15:46:15 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Baolin Wang <baolin.wang@...ux.alibaba.com>,
 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 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?

>  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?

>      done &
> done


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ