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]

Message-ID: <20100520152221.GR21799@erda.amd.com>
Date:	Thu, 20 May 2010 17:22:21 +0200
From:	Robert Richter <robert.richter@....com>
To:	Stephane Eranian <eranian@...gle.com>
CC:	Peter Zijlstra <peterz@...radead.org>, 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 20.05.10 08:13:43, Stephane Eranian wrote:
> What's wrong with creating pseudo-events for IBS? We'd have to pick
> two unused event codes. That would have the advantage of making it
> explicit you're using IBS. I think we could still use the precise_ip field
> if people are only interested in the IP. They would use PERF_SAMPLE_RAW
> if they need more.

For some key events this is fine and useful. But, if this has to be
used to programm all IBS features, it will introduce too much
implementation and maintenance effort. What you get then will probably
of less interest since users/tools want to have the raw sample data
for further processing. But maybe we agree already in this point, if
there is a demand we should provide pseudo events for important or
offen used events.

> >> > 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.
> >
> IBS is a sampling only feature. I suspect it would be okay to return 0 here
> or do as you said, count the number of IBS interrupts and multiply by the
> sampling period.

True, ibs can be used as an additional counter using the interrupt
only and dropping sampling data. I was already thinking of adding it
somehow to the list of available counters. But this is also later work
as its 64 bit extension.

> > Dunno, reconstruct sensible counters? Surely the software that uses IBS
> > does something useful with that data? What does libpfm do with the IBS
> > data?

Here are some use cases described:

 http://developer.amd.com/assets/AMD_IBS_paper_EN.pdf
 http://developer.amd.com/cpu/CodeAnalyst/assets/ISPASS2010_IBS_CA_abstract.pdf

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter@....com

--
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/