Re: [PATCH v1 01/11] perf/x86/core: Support KVM to assign a dedicated counter for guest PEBS
From: Liang, Kan
Date: Thu Mar 26 2020 - 10:03:16 EST
Hi Peter,
On 3/9/2020 3:28 PM, Liang, Kan wrote:
On 3/9/2020 11:05 AM, Peter Zijlstra wrote:
In the new proposal, KVM user is treated the same as other host
events with
event constraint. The scheduler is free to choose whether or not to
assign a
counter for it.
That's what it does, I understand that. I'm saying that that is creating
artificial contention.
Why is this needed anyway? Can't we force the guest to flush and then
move it over to a new counter?
Current perf scheduling is pure software behavior. KVM only traps the
MSR access. Itâs impossible for KVM to impact the guestâs scheduling
with current implementation.
To address the concern regarding to 'artificial contention', we have two
proposals.
Could you please take a look, and share your thoughts?
Proposal 1:
Reject the guest request, if host has to use the counter which occupied
by guest. At the meantime, host prints a warning.
I still think the contention should rarely happen in practical.
Personally, I prefer this proposal.
Proposal 2:
Add HW advisor for the scheduler in guest.
Starts from Architectural Perfmon Version 4, IA32_PERF_GLOBAL_INUSE MSR
is introduced. It provides an âInUseâ bit for each programmable
performance counter and fixed counter in the processor.
In perf, the scheduler will read the MSR and mask the âin usedâ
counters. I think we can use X86_FEATURE_HYPERVISOR to limit the check
in guest. For non-virtualization usage and host, nothing changed for
scheduler.
But there is still a problem for this proposal. Host may request a
counter later, which has been used by guest.
We can only do multiplexing or grab the counter just like proposal 1.
What do you think?
Thanks,
Kan
KVM only traps the MSR access. There is no MSR access during the
scheduling in guest.
KVM/host only knows the request counter, when guest tries to enable the
counter. It's too late for guest to start over.
Regarding to the artificial contention, as my understanding, it should
rarely happen in practical.
Cloud vendors have to explicitly set pebs option in qemu to enable PEBS
support for guest. They knows the environment well. They can avoid the
contention. (We may implement some patches for qemu/KVM later to
temporarily disable PEBS in runtime if they require.)
For now, I think we may print a warning when both host and guest require
the same counter. Host can get a clue from the warning.
Thanks,
Kan