lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 2 Aug 2018 11:18:01 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Peter Zijlstra <peterz@...radead.org>,
        Reinette Chatre <reinette.chatre@...el.com>
Cc:     tglx@...utronix.de, mingo@...hat.com, fenghua.yu@...el.com,
        tony.luck@...el.com, vikas.shivappa@...ux.intel.com,
        gavin.hindman@...el.com, jithu.joseph@...el.com, hpa@...or.com,
        x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] x86/intel_rdt and perf/x86: Fix lack of coordination
 with perf

On 08/02/2018 10:37 AM, Peter Zijlstra wrote:
>> I do not see how I can do so without incurring the cache hits and misses
>> from the data needed and instructions run by this interface. Could you
>> please share how I can do so and still obtain the accurate measurement
>> of cache residency of a specific memory region?
> That's the best you're going to get. You do _NOT_ get to use raw PMU.

Hi Peter,

This code is really fidgety.  It's really easily perturbed even by tiny
things like implicit cache accesses from the page walker filling the TLB
from the page tables.

Adding a bunch more code in the way is surely going to make it more
fragile and imprecise.

I totally understand not wanting to fill the tree with code hijacking
the raw PMU.  Is your reaction to this really around not wanting to
start down the slippery slope that ends up with lots of raw PMU "owners"?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ