All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qi Zheng <qi.zheng@linux.dev>
To: RCU <rcu@vger.kernel.org>, Yujie Liu <yujie.liu@intel.com>
Cc: oe-lkp@lists.linux.dev, lkp@intel.com,
	linux-kernel@vger.kernel.org,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Vlastimil Babka" <vbabka@suse.cz>, "Kirill Tkhai" <tkhai@ya.ru>,
	"Roman Gushchin" <roman.gushchin@linux.dev>,
	"Christian König" <christian.koenig@amd.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Davidlohr Bueso" <dave@stgolabs.net>,
	"Johannes Weiner" <hannes@cmpxchg.org>,
	"Michal Hocko" <mhocko@kernel.org>,
	"Muchun Song" <muchun.song@linux.dev>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	"Shakeel Butt" <shakeelb@google.com>,
	"Yang Shi" <shy828301@gmail.com>,
	linux-mm@kvack.org, ying.huang@intel.com, feng.tang@intel.com,
	fengwei.yin@intel.com
Subject: Re: [linus:master] [mm] f95bdb700b: stress-ng.ramfs.ops_per_sec -88.8% regression
Date: Thu, 25 May 2023 12:03:16 +0800	[thread overview]
Message-ID: <be04dc3e-a671-ec70-6cf6-70dc702f4184@linux.dev> (raw)
In-Reply-To: <bfb36563-fac9-4c84-96db-87dd28892088@linux.dev>



On 2023/5/24 19:56, Qi Zheng wrote:
> 
> 
> On 2023/5/24 19:08, Qi Zheng wrote:
> 
> [...]
> 
>>
>> Well, I just ran the following command and reproduced the result:
>>
>> stress-ng --timeout 60 --times --verify --metrics-brief --ramfs 9 &
>>
>> 1) with commit 42c9db3970483:
>>
>> stress-ng: info:  [11023] setting to a 60 second run per stressor
>> stress-ng: info:  [11023] dispatching hogs: 9 ramfs
>> stress-ng: info:  [11023] stressor       bogo ops real time  usr time 
>> sys time   bogo ops/s     bogo ops/s
>> stress-ng: info:  [11023]                           (secs)    (secs) 
>> (secs)   (real time) (usr+sys time)
>> stress-ng: info:  [11023] ramfs            774966     60.00     10.18 
>> 169.45     12915.89        4314.26
>> stress-ng: info:  [11023] for a 60.00s run time:
>> stress-ng: info:  [11023]    1920.11s available CPU time
>> stress-ng: info:  [11023]      10.18s user time   (  0.53%)
>> stress-ng: info:  [11023]     169.44s system time (  8.82%)
>> stress-ng: info:  [11023]     179.62s total time  (  9.35%)
>> stress-ng: info:  [11023] load average: 8.99 2.69 0.93
>> stress-ng: info:  [11023] successful run completed in 60.00s (1 min, 
>> 0.00 secs)
>>
>> 2) with commit f95bdb700bc6b:
>>
>> stress-ng: info:  [37676] dispatching hogs: 9 ramfs
>> stress-ng: info:  [37676] stressor       bogo ops real time  usr time 
>> sys time   bogo ops/s     bogo ops/s
>> stress-ng: info:  [37676]                           (secs)    (secs) 
>> (secs)   (real time) (usr+sys time)
>> stress-ng: info:  [37676] ramfs            168673     60.00      1.61 
>>   39.66      2811.08        4087.47
>> stress-ng: info:  [37676] for a 60.10s run time:
>> stress-ng: info:  [37676]    1923.36s available CPU time
>> stress-ng: info:  [37676]       1.60s user time   (  0.08%)
>> stress-ng: info:  [37676]      39.66s system time (  2.06%)
>> stress-ng: info:  [37676]      41.26s total time  (  2.15%)
>> stress-ng: info:  [37676] load average: 7.69 3.63 2.36
>> stress-ng: info:  [37676] successful run completed in 60.10s (1 min, 
>> 0.10 secs)
>>
>> The bogo ops/s (real time) did drop significantly.
>>
>> And the memory reclaimation was not triggered in the whole process. so
>> theoretically no one is in the read critical section of shrinker_srcu.
>>
>> Then I found that some stress-ng-ramfs processes were in
>> TASK_UNINTERRUPTIBLE state for a long time:
>>
>> root       42313  0.0  0.0  69592  2068 pts/0    S    19:00   0:00 
>> stress-ng-ramfs [run]
>> root       42314  0.0  0.0  69592  2068 pts/0    S    19:00   0:00 
>> stress-ng-ramfs [run]
>> root       42315  0.0  0.0  69592  2068 pts/0    S    19:00   0:00 
>> stress-ng-ramfs [run]
>> root       42316  0.0  0.0  69592  2068 pts/0    S    19:00   0:00 
>> stress-ng-ramfs [run]
>> root       42317  7.8  0.0  69592  1812 pts/0    D    19:00   0:02 
>> stress-ng-ramfs [run]
>> root       42318  0.0  0.0  69592  2068 pts/0    S    19:00   0:00 
>> stress-ng-ramfs [run]
>> root       42319  7.8  0.0  69592  1812 pts/0    D    19:00   0:02 
>> stress-ng-ramfs [run]
>> root       42320  0.0  0.0  69592  2068 pts/0    S    19:00   0:00 
>> stress-ng-ramfs [run]
>> root       42321  7.8  0.0  69592  1812 pts/0    D    19:00   0:02 
>> stress-ng-ramfs [run]
>> root       42322  0.0  0.0  69592  2068 pts/0    S    19:00   0:00 
>> stress-ng-ramfs [run]
>> root       42323  7.8  0.0  69592  1812 pts/0    D    19:00   0:02 
>> stress-ng-ramfs [run]
>> root       42324  0.0  0.0  69592  2068 pts/0    S    19:00   0:00 
>> stress-ng-ramfs [run]
>> root       42325  7.8  0.0  69592  1812 pts/0    D    19:00   0:02 
>> stress-ng-ramfs [run]
>> root       42326  0.0  0.0  69592  2068 pts/0    S    19:00   0:00 
>> stress-ng-ramfs [run]
>> root       42327  7.9  0.0  69592  1812 pts/0    D    19:00   0:02 
>> stress-ng-ramfs [run]
>> root       42328  7.9  0.0  69592  1812 pts/0    D    19:00   0:02 
>> stress-ng-ramfs [run]
>> root       42329  7.9  0.0  69592  1812 pts/0    D    19:00   0:02 
>> stress-ng-ramfs [run]
>> root       42330  7.9  0.0  69592  1556 pts/0    D    19:00   0:02 
>> stress-ng-ramfs [run]
>>
>> Their call stack is as follows:
>>
>> cat /proc/42330/stack
>>
>> [<0>] __synchronize_srcu.part.21+0x83/0xb0
>> [<0>] unregister_shrinker+0x85/0xb0
>> [<0>] deactivate_locked_super+0x27/0x70
>> [<0>] cleanup_mnt+0xb8/0x140
>> [<0>] task_work_run+0x65/0x90
>> [<0>] exit_to_user_mode_prepare+0x1ba/0x1c0
>> [<0>] syscall_exit_to_user_mode+0x1b/0x40
>> [<0>] do_syscall_64+0x44/0x80
>> [<0>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
>>
>> + RCU folks, Is this result as expected? I would have thought that
>> synchronize_srcu() should return quickly if no one is in the read
>> critical section. :(
>>
> 
> With the following changes, ops/s can return to previous levels:

Or just set rcu_expedited to 1:
	echo 1 > /sys/kernel/rcu_expedited

> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index db2ed6e08f67..90f541b07cd1 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -763,7 +763,7 @@ void unregister_shrinker(struct shrinker *shrinker)
>          debugfs_entry = shrinker_debugfs_remove(shrinker);
>          up_write(&shrinker_rwsem);
> 
> -       synchronize_srcu(&shrinker_srcu);
> +       synchronize_srcu_expedited(&shrinker_srcu);
> 
>          debugfs_remove_recursive(debugfs_entry);
> 
> stress-ng: info:  [13159] dispatching hogs: 9 ramfs
> stress-ng: info:  [13159] stressor       bogo ops real time  usr time 
> sys time   bogo ops/s     bogo ops/s
> stress-ng: info:  [13159]                           (secs)    (secs) 
> (secs)   (real time) (usr+sys time)
> stress-ng: info:  [13159] ramfs            710062     60.00      9.63 
> 157.26     11834.18        4254.75
> stress-ng: info:  [13159] for a 60.00s run time:
> stress-ng: info:  [13159]    1920.14s available CPU time
> stress-ng: info:  [13159]       9.62s user time   (  0.50%)
> stress-ng: info:  [13159]     157.26s system time (  8.19%)
> stress-ng: info:  [13159]     166.88s total time  (  8.69%)
> stress-ng: info:  [13159] load average: 9.49 4.02 1.65
> stress-ng: info:  [13159] successful run completed in 60.00s (1 min, 
> 0.00 secs)
> 
> Can we make synchronize_srcu() call synchronize_srcu_expedited() when no
> one is in the read critical section?
> 
>>
> 

-- 
Thanks,
Qi

  reply	other threads:[~2023-05-25  4:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-23  1:35 [linus:master] [mm] f95bdb700b: stress-ng.ramfs.ops_per_sec -88.8% regression kernel test robot
2023-05-23  3:05 ` Qi Zheng
2023-05-24  7:31   ` Yujie Liu
2023-05-24  8:36     ` Qi Zheng
2023-05-24 11:08       ` Qi Zheng
2023-05-24 11:22         ` Qi Zheng
2023-05-24 11:56         ` Qi Zheng
2023-05-25  4:03           ` Qi Zheng [this message]
2023-05-27 11:14             ` Paul E. McKenney
2023-05-29  2:39               ` Qi Zheng
2023-05-29 12:51                 ` Paul E. McKenney
2023-05-30  3:07                   ` Qi Zheng
2023-06-01  0:57                     ` Kirill Tkhai
2023-06-01  8:34                       ` Qi Zheng
     [not found]                         ` <932751685611907@mail.yandex.ru>
2023-06-01 10:44                           ` Qi Zheng
2023-06-18 10:59 ` Linux regression tracking #adding (Thorsten Leemhuis)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=be04dc3e-a671-ec70-6cf6-70dc702f4184@linux.dev \
    --to=qi.zheng@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=christian.koenig@amd.com \
    --cc=dave@stgolabs.net \
    --cc=david@redhat.com \
    --cc=feng.tang@intel.com \
    --cc=fengwei.yin@intel.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=mhocko@kernel.org \
    --cc=muchun.song@linux.dev \
    --cc=oe-lkp@lists.linux.dev \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeelb@google.com \
    --cc=shy828301@gmail.com \
    --cc=tkhai@ya.ru \
    --cc=vbabka@suse.cz \
    --cc=ying.huang@intel.com \
    --cc=yujie.liu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.