[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEXW_YScFnFG0Y1NgFS7KGS6s9CoXJ3ZQB++6udyK38mcJ=1xg@mail.gmail.com>
Date: Wed, 23 Aug 2023 09:50:37 -0400
From: Joel Fernandes <joel@...lfernandes.org>
To: Z qiang <qiang.zhang1211@...il.com>
Cc: "Paul E. McKenney" <paulmck@...nel.org>, rcu@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: rcutorture: Can not Disable RT throttling
On Tue, Aug 22, 2023 at 3:37 AM Z qiang <qiang.zhang1211@...il.com> wrote:
>
> When running build-in rcutorture tests in 6.5.0-rc4-rt, and found that,
> although the value of /proc/sys/kernel/sched_rt_runtime_us is -1,
>
> cat /sys/kernel/debug/sched/debug
> ....
> rt_rq[6]:
> .rt_nr_running : 4
> .rt_nr_migratory : 0
> .rt_throttled : 0
> .rt_time : 0.000000
> .rt_runtime : 950.000000
>
> but the rt_runtime still is 950.000000.
> set sysctl_sched_rt_runtime in rcu_torture_disable_rt_throttle()
> does not disable rt-throttling.
I think you have hit a bug. I think the problem is
rcu_torture_disable_rt_throttle() modifies the sysctl knobs, but does
not change def_rt_bandwidth and reinitialize the rt_rq. I think we
need to call sched_rt_do_global() like the sysfs handler does, or
change the sysctl knobs to be earlier in the boot process before the
rt_rq are initialized.
Or better yet (not sure if it is possible) trigger the sysctl change
via the sysctl layer and let it do the same logic.
Thoughts?
Thanks.
Powered by blists - more mailing lists