From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul E. McKenney" Subject: Re: [RFC] Make need_resched() return true when rcu_urgent_qs requested Date: Wed, 11 Jul 2018 14:08:28 -0700 Message-ID: <20180711210828.GD3593@linux.vnet.ibm.com> References: <1531169145.26547.8.camel@infradead.org> <20180709210532.GH3593@linux.vnet.ibm.com> <20180709220823.GA18045@linux.vnet.ibm.com> <1531319025.8759.57.camel@infradead.org> <20180711144303.GQ3593@linux.vnet.ibm.com> <20180711164952.GA29994@linux.vnet.ibm.com> <9ee4d6fd-02e2-2c73-36a7-36ef4f6413b0@de.ibm.com> <20180711201759.GB3593@linux.vnet.ibm.com> <1531340384.8759.86.camel@infradead.org> Reply-To: paulmck@linux.vnet.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Christian Borntraeger , Peter Zijlstra , mhillenb@amazon.de, linux-kernel , kvm To: David Woodhouse Return-path: Content-Disposition: inline In-Reply-To: <1531340384.8759.86.camel@infradead.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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