linux-kernel - Re: [PATCH] perf_counter: Always return the parent counter id to userspace

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] [day] [month] [year] [list]

Message-ID: <20090722051052.GC9029@kryten>
Date:	Wed, 22 Jul 2009 15:10:53 +1000
From:	Anton Blanchard <anton@...ba.org>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	mingo@...e.hu, paulus@...ba.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] perf_counter: Always return the parent counter id to
	userspace

 
Hi Peter,
 
> Hmm, ok, so how about something like this:
> 
> ---
> Subject: perf_counter: PERF_SAMPLE_ID and inherited counters
> 
> Anton noted that for inherited counters the counter-id as provided by
> PERF_SAMPLE_ID isn't mappable to the id found through PERF_RECORD_ID
> because each inherited counter gets its own id.
> 
> His suggestion was to always return the parent counter id, since that is
> the primary counter id as exposed. However, these inherited counters
> have a unique identifier so that events like PERF_EVENT_PERIOD and
> PERF_EVENT_THROTTLE can be specific about which counter gets modified,
> which is important when trying to normalize the sample streams.
> 
> This patch removes PERF_EVENT_PERIOD in favour of PERF_SAMPLE_PERIOD,
> which is more useful anyway, since changing periods became a lot more
> common than initially thought -- rendering PERF_EVENT_PERIOD the less
> useful solution (also, PERF_SAMPLE_PERIOD reports the more accurate
> value, since it reports the value used to trigger the overflow, whereas
> PERF_EVENT_PERIOD simply reports the requested period changed, which
> might only take effect on the next cycle).
> 
> This still leaves us PERF_EVENT_THROTTLE to consider, but since that
> _should_ be a rare occurrence, and linking it to a primary id is the
> most useful bit to diagnose the problem, we introduce a
> PERF_SAMPLE_STREAM_ID, for those few cases where the full reconstruction
> is important.

I gave it a try and the perf.data results make much more sense.
Thanks!

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