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: Mon, 23 Jul 2018 05:22:31 -0700 Message-ID: <20180723122230.GM12945@linux.vnet.ibm.com> References: <20180712125351.GP3593@linux.vnet.ibm.com> <20180712161704.GA20726@linux.vnet.ibm.com> <20180716154015.GA21419@linux.vnet.ibm.com> <1531815548.19223.23.camel@infradead.org> <20180717125653.GH12945@linux.vnet.ibm.com> <20180718153628.GA24359@linux.vnet.ibm.com> <1531929711.3414.29.camel@infradead.org> <20180718163712.GB12945@linux.vnet.ibm.com> <20180719170953.GA17730@linux.vnet.ibm.com> <1532333339.14652.12.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: <1532333339.14652.12.camel@infradead.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Mon, Jul 23, 2018 at 10:08:59AM +0200, David Woodhouse wrote: > On Thu, 2018-07-19 at 10:09 -0700, Paul E. McKenney wrote: > > > > Of course, the real reason for the lack of fault on your part will not > > because I believe I found the bug elsewhere, but instead because I will > > be dropping your patch (and mine as well) on Frederic's advice.  ;-) > > You're keeping the need_resched() one though? Yes. This the current commit in -rcu (which will change when I rebase onto v4.19-rc1, if not earlier): fcf0407e6e63 ("rcu: Make need_resched() respond to urgent RCU-QS needs") > And we are still left with the fact that CONTEXT_TRACKING_FORCE is > making the existing code in guest_enter_irqoff() do the wrong thing for > !NO_HZ_FULL. But in fact the rcu_virt_note_context_switch() there is > completely redundant now we fixed need_resched(), so can be dropped, > leaving only the rcu_user_enter/exit calls for the NO_HZ_FULL case? I am not yet convinced that we know exactly the right thing to be doing for guest OSes for either value of NO_HZ_FULL, much less that we are actually doing it. ;-) But what does your testing say? Thanx, Paul