[lkml]   [2018]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH V2 0/6] perf/core and x86/intel_rdt: Fix lack of coordination with perf
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

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


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(-)

 \ /
  Last update: 2018-09-04 18:51    [W:0.110 / U:4.800 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site