Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753292AbbBJVBF (ORCPT ); Tue, 10 Feb 2015 16:01:05 -0500 Received: from mail-la0-f48.google.com ([209.85.215.48]:42795 "EHLO mail-la0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752030AbbBJVBC (ORCPT ); Tue, 10 Feb 2015 16:01:02 -0500 MIME-Version: 1.0 In-Reply-To: <20150210204241.GV4166@linux.vnet.ibm.com> References: <1423579310-24555-1-git-send-email-riel@redhat.com> <1423579310-24555-7-git-send-email-riel@redhat.com> <54DA630D.6020601@amacapital.net> <20150210201402.GU4166@linux.vnet.ibm.com> <20150210204241.GV4166@linux.vnet.ibm.com> From: Andy Lutomirski Date: Tue, 10 Feb 2015 13:00:35 -0800 Message-ID: Subject: Re: [PATCH 6/6] kvm,rcu,nohz: use RCU extended quiescent state when running KVM guest To: Paul McKenney Cc: Rik van Riel , Will Deacon , "linux-kernel@vger.kernel.org" , Catalin Marinas , =?UTF-8?B?RnLDqWTDqXJpYyBXZWlzYmVja2Vy?= , kvm list , Marcelo Tosatti , Christian Borntraeger , Ingo Molnar , Oleg Nesterov , Luiz Capitulino , Paolo Bonzini Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4065 Lines: 89 On Tue, Feb 10, 2015 at 12:42 PM, Paul E. McKenney wrote: > On Tue, Feb 10, 2015 at 12:19:28PM -0800, Andy Lutomirski wrote: >> On Tue, Feb 10, 2015 at 12:14 PM, Paul E. McKenney >> wrote: >> > On Tue, Feb 10, 2015 at 11:59:09AM -0800, Andy Lutomirski wrote: >> >> On 02/10/2015 06:41 AM, riel@redhat.com wrote: >> >> >From: Rik van Riel >> >> > >> >> >The host kernel is not doing anything while the CPU is executing >> >> >a KVM guest VCPU, so it can be marked as being in an extended >> >> >quiescent state, identical to that used when running user space >> >> >code. >> >> > >> >> >The only exception to that rule is when the host handles an >> >> >interrupt, which is already handled by the irq code, which >> >> >calls rcu_irq_enter and rcu_irq_exit. >> >> > >> >> >The guest_enter and guest_exit functions already switch vtime >> >> >accounting independent of context tracking. Leave those calls >> >> >where they are, instead of moving them into the context tracking >> >> >code. >> >> > >> >> >Signed-off-by: Rik van Riel >> >> >--- >> >> > include/linux/context_tracking.h | 6 ++++++ >> >> > include/linux/context_tracking_state.h | 1 + >> >> > include/linux/kvm_host.h | 3 ++- >> >> > 3 files changed, 9 insertions(+), 1 deletion(-) >> >> > >> >> >diff --git a/include/linux/context_tracking.h b/include/linux/context_tracking.h >> >> >index 954253283709..b65fd1420e53 100644 >> >> >--- a/include/linux/context_tracking.h >> >> >+++ b/include/linux/context_tracking.h >> >> >@@ -80,10 +80,16 @@ static inline void guest_enter(void) >> >> > vtime_guest_enter(current); >> >> > else >> >> > current->flags |= PF_VCPU; >> >> >+ >> >> >+ if (context_tracking_is_enabled()) >> >> >+ context_tracking_enter(IN_GUEST); >> >> >> >> Why the if statement? >> >> >> >> Also, have you checked how much this hurts guest lightweight >> >> entry/exit latency? Context tracking is shockingly expensive for >> >> reasons I don't fully understand, but hopefully most of it is the >> >> vtime stuff. (Context tracking is *so* expensive that I almost >> >> think we should set the performance taint flag if we enable it, >> >> assuming that flag ended up getting merged. Also, we should make >> >> context tracking faster.) >> > >> > It turns out that context_tracking_is_enabled() is a static inline >> > that uses a static_key, so the overhead should be minimal on platforms >> > having a full implementation of static keys. >> >> Shouldn't we just fold that into context_tracking_xyz_enter? > > If I am not getting too confused, Rik did that initially, but it caused > some pain for the ARM guys. I don't see a performance downside, at > least not for a modern compiler that does a decent job of inlining. It's more of a tidiness issue to me than a performance issue. > >> Also, why does the vtime stuff depend on RCU extended quiescent >> states? To me, they seem mostly orthogonal other than the fact that >> they hook into the same places. > > I might be missing your point, but... > > If there are no scheduling-clock interrupts, then the CPU needs to be > in an extended quiescent state, otherwise you will get RCU CPU stall > warnings and eventually OOM. Similarly, if there are no scheduling-clock > interupts, then you need to compute the vtime stuff based on start times > and deltas instead of relying on a scheduling-clock interrupt that never > comes. So it isn't that the vtime and RCU stuff are directly related, > but rather that they both must take evasive action if there are to be > no scheduling-clock interrupts for an extended time period. I'm probably missing something, but isn't vtime also used for accurate CPU time stats? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/