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