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:	Fri, 12 Nov 2010 11:49:16 +0100
From:	Stephane Eranian <eranian@...gle.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
	Andi Kleen <ak@...ux.intel.com>, linux-kernel@...r.kernel.org,
	fweisbec@...il.com, mingo@...e.hu, acme@...hat.com
Subject: Re: [PATCH 2/3] perf: Add support for extra parameters for raw events

On Fri, Nov 12, 2010 at 11:27 AM, Andi Kleen <andi@...stfloor.org> wrote:
> On Thu, Nov 11, 2010 at 09:37:38PM +0100, Peter Zijlstra wrote:
>> On Thu, 2010-11-11 at 21:12 +0100, Andi Kleen wrote:
>> > > Also, I think we can use the same mechanism to program the
>> > > PEBS-load-latency MSR, right?
>> >
>> > I haven't looked at that, but if it's a per core resource
>> > the infrastructure can be reused at least.
>>
>> Can't remember if the load-latency msr is per-core, but its an extra reg
>> that needs to be set.
>
> Ok. I guess it shouldn't be too hard to add.
>
> Load-latency is pretty useful too.
>
Yes, it is to figure out where cache misses are.

>>
>> The nhm/wsm LBR config msr is per-core though, so that could use your
>> infrastructure too.
>
> Stephane mentioned that too. Not right now, but perhaps later I'll
> look at using this.
>
The difficulty with PEBS-LL (load latency) is not so much the encoding of the
latency. It is more how to expose the data back to user. You get a full PEBS
record for each miss. So you get the PEBS machine state + data addr, miss
latency, and data source (where did the line come from). We have already
discussed how to expose machine state in general. I'll work on a patch for this.
So we can get the general PEBS machine state out. However, the question is
how do we expose data addr, latency, data source? We can reuse the
SAMPLE_ADDR for the data address. Sample IP would point to the load
instruction (with help from LBR to correct the off by one issue). For
the latency
and data source, I proposed using pseudo regs and leveraging the sampled machine
state mechanism. An alternative may be to define a new record type that would b
generic enough to be reusable, for instance { instr_addr, data_addr,
latency, data_src, flags; }.

But let's fix OFFCORE_RESPONSE_* first.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ