linux-kernel - Re: perf_counter: request for three more sample data options

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, 03 Apr 2009 09:01:04 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Corey Ashford <cjashfor@...ux.vnet.ibm.com>
Cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Paul Mackerras <paulus@...ba.org>
Subject: Re: perf_counter: request for three more sample data options

On Thu, 2009-04-02 at 18:46 -0700, Corey Ashford wrote:
> Currently, perf_counter has the ability to record the following on event 
> counter overflow:
> 
> Instruction Pointer
> Call chain
> Group counter values
> Thread id
> 
> To give perf_counter similar capabilities to perfmon2's default sampling 
>   module, I'd like the following additional sample data to be added.
> 
> Time stamp
 
Rather hard actually, to provide a decent timestamp from NMI context.

> CPU number

Could do I guess.

> Thread Group Id

As in the process id? PERF_RECORD_TID already provides that.

> I'd suggest the following
> 
> enum perf_counter_record_format {
>          PERF_RECORD_IP          = 1U << 0,
>          PERF_RECORD_TID         = 1U << 1,
>          PERF_RECORD_TGID        = 1U << 2,
> -        PERF_RECORD_GROUP       = 1U << 2,
> +        PERF_RECORD_GROUP       = 1U << 3,
> -        PERF_RECORD_CALLCHAIN   = 1U << 3,
> +        PERF_RECORD_CALLCHAIN   = 1U << 4,
> +        PERF_RECORD_CPU_ID      = 1U << 5,
> +        PERF_RECORD_TIMESTAMP   = 1U << 6,
> };
> 
> And of course the obvious changes to perf_event_type.
> 
> I would expect that CPU ID would be 32 bits, and the timestamp to be the 
> 64-bit current time.  TGID is the same size as TID.

Right, so PREF_RECORD_TID provides:

 { u32 pid, tid; }

PERF_RECORD_TIMESTAMP would provide something like:

 { u64 time; }

and per our u64 alignment rule, PERF_RECORD_CPU would provide

 { u64 cpuid; }

unless you can think of anything else to stuff in there?

> I am guessing the only difficult thing here would be obtaining the 
> current time from an IRQ, especially NMI handler.  Is this difficult?

Yes, quite :-) I'll have to see what we can do there -- we could do a
best effort thing with little to no guarantees I think.

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