On Wed, Sep 13, 2023 at 04:30:20PM -0400, Joel Fernandes wrote: > On Mon, Sep 11, 2023 at 4:16 AM Paul E. McKenney <paulmck@xxxxxxxxxx> wrote: > [..] > > > I am digging deeper to see why the rcu_preempt thread cannot be pushed out > > > and then I'll also look at why is it being pushed out in the first place. > > > > > > At least I have a strong repro now running 5 instances of TREE03 in parallel > > > for several hours. > > > > Very good! Then why not boot with rcutorture.onoff_interval=0 and see if > > the problem still occurs? If yes, then there is definitely some reason > > other than CPU hotplug that makes this happen. > > Hi Paul, > So looks so far like onoff_interval=0 makes the issue disappear. So > likely hotplug related. I am ok with doing the cpus_read_lock during > boost testing and seeing if that fixes it. If it does, I can move on > to the next thing in my backlog. > > What do you think? Or should I spend more time root-causing it? It is > most like runaway RT threads combined with the CPU hotplug threads, > making scheduling of the rcu_preempt thread not happen. But I can't > say for sure without more/better tracing (Speaking of better tracing, > I am adding core-dump support to rcutorture, but it is not there yet). This would not be the first time rcutorture has had trouble with those threads, so I am for adding the cpus_read_lock(). Additional root-causing might be helpful, but then again, you might have higher priority things to worry about. ;-) Thanx, Paul
