linux-kernel - Re: [PATCH/RFC 1/2] perfcounters: provide a way to read the current value of interrupting counters

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: <18879.21884.162961.690031@cargo.ozlabs.ibm.com>
Date:	Tue, 17 Mar 2009 18:47:08 +1100
From:	Paul Mackerras <paulus@...ba.org>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH/RFC 1/2] perfcounters: provide a way to read the
 current value of interrupting counters

Peter Zijlstra writes:

> I'm not sure I understand why. It seems to me you're either interested
> in sample data, that is {tid,ip,counter} like things, or you want raw
> count values.

It was specifically requested by people porting PAPI to PCL, and it
seems like a reasonable request.

> This seems unrelated, what will stop us now from adding record_type
> values? PERF_RECORD_CALLCHAIN is one in particular I'd like to add soon.

I think we should make record_type a bitset rather than a single
value, and define bits for recording the callchain as well as various
other interesting things.

> This is a bit bothersome, as we then have no unique identifier anymore.
> 
> Currently the group record type writes things like {hw_event->type,
> counter} which is ambiguous since we really have a 65bit id space. So I
> was thinking of making that {fd, counter} to at least have a unique
> identifier in there.

The fd is already not a unique identifier - think about dup().

The hw_event->type values are not really necessary, in fact, since the
group members will always be read out in the order that they were
added to the group.  The only time there might be any possibility of
confusion is if a new member is added after some samples have already
been taken (or a member is removed) - then we'll get new records being
added to the event queue being a different size from those already in
the queue.  But that's a somewhat different problem which isn't really
solved by having the type values in there.

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