On Wed, Jul 11, 2018 at 09:19:44PM +0100, David Woodhouse wrote: > On Wed, 2018-07-11 at 13:17 -0700, Paul E. McKenney wrote: > > As I understand it, they would like to have their guest run uninterrupted > > for extended times. Because rcu_virt_note_context_switch() is a > > point-in-time quiescent state, it cannot tell RCU about the extended > > quiescent state. > > > > Should we replace the current calls to rcu_virt_note_context_switch() > > with rcu_kvm_enter() and rcu_kvm_exit()? Would that be better > > than the below architecture-by-architecture approach? > > Yes it would. I was already starting to mutter about needing the same > for ARM and POWER. I'll do a v3 (incorporating your fixes too) in the > morning. > > Thanks. > > Also... why in $DEITY's name was the existing > rcu_virt_note_context_switch() not actually sufficient? If we had that > there, why did we need an additional explicit calls to rcu_all_qs() in > the KVM loop, or the more complex fixes to need_resched() which > ultimately had the same effect, to avoid ten-second latencies? My guess is that this was because control passed through the rcu_virt_note_context_switch() only once, and then subsequent scheduling-clock interrupts bypassed this code. But that is just a guess. I need to defer to someone who understands the KVM code better than I do. Thanx, Paul
