On 02/10/2015 06:41 AM, r...@redhat.com wrote:
From: Rik van Riel <r...@redhat.com>
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 <r...@redhat.com>
---
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.)
--Andy
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
