Re: [PATCH V2 0/6] perf/core and x86/intel_rdt: Fix lack of coordination with perf

[Reinette Chatre]

Dear Maintainers,

This series is still needed to complete the initial cache pseudo-locking
implementation and still applies cleanly to both x86/cache of tip.git as
well as v4.19-rc2.

At this time users are unable to measure the success of their cache
pseudo-locked regions and either need to manually apply this series or
revert the commit that disables the current measurement mechanisms
"4a7a54a55e7237386cacc73f173e74329773ac93 x86/intel_rdt: Disable PMU
access".

Is there perhaps an opportunity to include this series into v4.19?
Patches 2-6 from this series fixes code that does not exist in earlier
kernels. Patch 1 was suggested by Peter and is a fix to perf.

Your consideration would be greatly appreciated.

Thank you

Reinette

On 8/16/2018 1:16 PM, Reinette Chatre wrote:
> Dear Maintainers,
> 
> This is the second attempt at fixing the lack of coordination between the
> pseudo-locking measurement code and perf. Thank you very much for your
> feedback on the first version. The entire solution, including the cover
> letter, has been reworked based on your feedback, while submitted as a V2,
> none of the patches from V1 remained.
> 
> Changes since V1:
> - Use in-kernel interface to perf.
> - Do not write directly to PMU registers.
> - Do not introduce another PMU owner. perf maintains role as performing
>   resource arbitration for PMU.
> - User space is able to use perf and resctrl at the same time.
> - event_base_rdpmc is accessed and used only within an interrupts
>   disabled section.
> - Internals of events are never accessed directly, inline function used.
> - Due to "pinned" usage the scheduling of event may have failed.  Error
>   state is checked in recommended way and have a credible error
>   handling.
> - use X86_CONFIG
> 
> This code is based on the x86/cache branch of tip.git
> 
> The success of Cache Pseudo-Locking, as measured by how many cache lines
> from a physical memory region has been locked to cache, can be measured
> via the use of hardware performance events. Specifically, the number of
> cache hits and misses reading a memory region after it has been
> pseudo-locked to cache. This measurement is triggered via the resctrl
> debugfs interface.
> 
> The current solution accesses performance counters and their configuration
> registers directly without coordination with other performance event users
> (perf).
> Two of the issues that exist with the current solution:
> - By writing to the performance monitoring registers directly a new owner
>   for these resources is introduced. The perf infrastructure already exist
>   to perform resource arbitration and the in-kernel infrastructure should
>   be used to do so.
> - The current lack of coordination with perf will have consequences any time
>   two users, for example perf and cache pseudo-locking, attempt to do any
>   kind of measurement at the same time.
> 
> In this series the measurement of Cache Pseudo-Lock regions is moved to use
> the in-kernel interface to perf. During the rework of the measurement
> function the L2 and L3 cache measurements are separated to avoid the
> additional code needed to decide on which measurement causing unrelated
> cache hits and misses.
> 
> Your feedback on this work will be greatly appreciated.
> 
> Reinette
> 
> Reinette Chatre (6):
>   perf/core: Add sanity check to deal with pinned event failure
>   x86/intel_rdt: Remove local register variables
>   x86/intel_rdt: Create required perf event attributes
>   x86/intel_rdt: Add helper to obtain performance counter index
>   x86/intel_rdt: Use perf infrastructure for measurements
>   x86/intel_rdt: Re-enable pseudo-lock measurements
> 
>  Documentation/x86/intel_rdt_ui.txt          |  22 +-
>  arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c | 419 ++++++++++++++------
>  kernel/events/core.c                        |   6 +
>  3 files changed, 310 insertions(+), 137 deletions(-)
>