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]

Message-ID: <49D5B9E7.1020400@linux.vnet.ibm.com>
Date:	Fri, 03 Apr 2009 00:25:27 -0700
From:	Corey Ashford <cjashfor@...ux.vnet.ibm.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
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

Thank you for your reply, Peter.

Peter Zijlstra wrote:
> 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; }

Ah, I didn't know that.  Ok, that's only two things I want then :)

> 
> PERF_RECORD_TIMESTAMP would provide something like:
> 
>  { u64 time; }

Yep.

> 
> and per our u64 alignment rule, PERF_RECORD_CPU would provide
> 
>  { u64 cpuid; }
> 
> unless you can think of anything else to stuff in there?

We could leave the upper 32-bits reserved for now.  Perhaps someone 
later will come up with some nice info to put 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.
> 

Best effort would be fine, I think.  I would assume that means that 
99.9% of the time, you'll get a correct timestamp, and the rest are 
rubbish?  Or would there be a way to detect when you're not able to give 
a correct timestamp and in that case replace the timestamp field with a 
special sentinel, like all hex f's?

Regards,

- Corey

Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
cjashfor@...ibm.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/