[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <77383a1e-f343-7529-24cf-874f0999507d@intel.com>
Date: Fri, 21 Sep 2018 09:49:48 -0700
From: Reinette Chatre <reinette.chatre@...el.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: tglx@...utronix.de, fenghua.yu@...el.com, tony.luck@...el.com,
mingo@...hat.com, acme@...nel.org, gavin.hindman@...el.com,
jithu.joseph@...el.com, dave.hansen@...el.com, hpa@...or.com,
x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V5 0/6] perf and x86/intel_rdt: Fix lack of coordination
with perf
Dear Maintainers,
On 9/20/2018 7:11 AM, Peter Zijlstra wrote:
> On Wed, Sep 19, 2018 at 10:29:05AM -0700, Reinette Chatre wrote:
>> Reinette Chatre (6):
>> perf/core: Add sanity check to deal with pinned event failure
>> perf/x86: Add helper to obtain performance counter index
>> x86/intel_rdt: Remove local register variables
>> x86/intel_rdt: Create required perf event attributes
>> 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/events/core.c | 21 ++
>> arch/x86/include/asm/perf_event.h | 1 +
>> arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c | 372 ++++++++++++--------
>> kernel/events/core.c | 6 +
>> 5 files changed, 261 insertions(+), 161 deletions(-)
>
> Yeah, these look good, thanks!
>
> Acked-by: Peter Zijlstra (Intel) <peterz@...radead.org>
>
Could you please consider this series for inclusion into v4.19?
- This series is needed to complete the initial cache pseudo-locking
enabling that is first introduced in v4.19. Without this series users
are able to create pseudo-locked regions but unable to accurately
measure their success.
- This is not adding a new feature of pseudo-locked region measurement
but fixing the existing measurement code that was disabled after found
to be poorly integrated.
- This series consists out of 6 patches. Patches 2 to 6 are either new
code in support of this fix or fixes to code that does not exist in
kernels before v4.19.
- Patch 1 is a fix to existing code. It is small, was suggested by, and
does have support from maintainer. Even so, if it is felt that this is
too risky then patches 2 to 6 could still be merged since it does not
actually depend on patch 1. In retrospect I should have submitted it
separately.
Your consideration would be greatly appreciated.
Thank you
Reinette
Powered by blists - more mailing lists