This article throws some light onto things:

https://lwn.net/Articles/518953/

"Second, the greater the number of idle CPUs, the more work RCU must do
when forcing quiescent states. Yes, the busier the system, the less work
RCU needs to do! The reason for the extra work is that RCU is not
permitted to disturb idle CPUs for energy-efficiency reasons. RCU must
therefore probe a per-CPU data structure to read out idleness state
during each grace period, likely incurring a cache miss on each such
probe."

Just to add, I running the VM with say 4 CPUs, all are which are idle.

In my experiments on 3.19 and 4.2, kernels, kvm is not being used on the
host, so we have QEMU emulating N CPUs with just 1 host CPU.  Plus a
loaded host means that this single CPU is busy and we have potentially
large latencies serving the N virtual CPUs in the VM. I think that's
part of the issue; large latencies from the host with a N-to-1 virt to
host mapping meaning that we are tripping the RCU grace periods.

To try and help RCU kthreads from suffering from delays, I added the
following kernel parameters to the VM:

rcu_nocb_poll rcutree.kthread_prio=90 rcuperf.verbose=1

I was able to run an 8 CPU VM without any RCU issues with the host CPU
being hammered to death with stress-ng.  I also then cranked down the
RCU stall grace period to just 5 seconds to see how easy I can trip the
issue with this more extreme setting using:

echo 5 > /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout

and again, no RCU issues.

@Martin,

can you try using the following kernel parameters on the VM and see if
this helps:

rcu_nocb_poll rcutree.kthread_prio=90 rcuperf.verbose=1

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1531768

Title:
  [arm64] lockups some time after booting

To manage notifications about this bug go to:
https://bugs.launchpad.net/auto-package-testing/+bug/1531768/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to