linux-kernel - Re: [PATCH 1/7] perf: introduce raw_type attribute to specify the type of a raw sample

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, 20 May 2010 12:37:39 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Stephane Eranian <eranian@...gle.com>
Cc:	Robert Richter <robert.richter@....com>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	Paul Mackerras <paulus@...ba.org>,
	David Miller <davem@...emloft.net>,
	Will Deacon <will.deacon@....com>,
	Paul Mundt <lethal@...ux-sh.org>
Subject: Re: [PATCH 1/7] perf: introduce raw_type attribute to specify the 
 type of a raw sample

On Thu, 2010-05-20 at 11:42 +0200, Stephane Eranian wrote:

> > For Instruction-Fetch:

> >  32:47 latency       (r/w)

> Your are mixing output and input parameters.
> 
> The only input parameters you have are:
> - sample-period, enable, random
> The rest is output only.

Ah, my bad, I thought it was a r/w field.

> > encode these IBS things as:
> >
> >  0x87 Instruction Fetch Stall -- Ins-Fetch
> >  0xC0 Retired Instructions    -- Ins-Exec
> >
> I think those events do not map to the behavior of IBS. We have
> add that discussion before.

Hrm,. so there are no regular events that count the same thing as the
IBS things? That really sucks.

So yeah, you might as well expose it as a whole separate PMU using Lin's
stuff.

> > The Ins-Exec will have to re-construct the actual event->count by adding
> > sample-period on each interrupt, as it seems we lack an actual counter
> > in hardware.
> >
> For what? counting mode?

Yeah, events are supposed to count.

> > Furthermore, these counters will have to deal with sample-period > 2^16
> > by 'ignoring' interrupts until we get ->period_left down to 0.
> >
> Well, it's not 2^16, it's 2^20 but bottom 4 bits must be zero.
> What about simply failing perf_event_open() is sample_period does not fit the
> constraint?

Why, its simple enough to ignore a few interrupts, we do the same for
all other implementations.

> > The extra data could possibly be exposed through attaching non-sampling
> > group events and using SAMPLE_READ, like L1-misses, although
> > reconstructing the count from just one bit seems 'interesting'.
> >
> > The IbsFetchLinAd/IbsOpRip would go straight into PERF_SAMPLE_IP by
> > replacing pt_regs->ip I guess.
> >
> > IbsDcLinAd goes into PERF_SAMPLE_ADDR
> >
> What about the rest, the TLB, alignment, data sources?

Dunno, reconstruct sensible counters? Surely the software that uses IBS
does something useful with that data? What does libpfm do with the IBS
data?
--
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/