linux-kernel - Re: [RFC PATCH 1/3] Unified trace buffer

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:	Thu, 25 Sep 2008 14:14:46 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Martin Bligh <mbligh@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Martin Bligh <mbligh@...igh.org>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	prasad@...ux.vnet.ibm.com,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	David Wilder <dwilder@...ibm.com>, hch@....de,
	Tom Zanussi <zanussi@...cast.net>,
	Steven Rostedt <srostedt@...hat.com>
Subject: Re: [RFC PATCH 1/3] Unified trace buffer

Ingo Molnar wrote:
> * Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>
>   
>> On Thu, 25 Sep 2008, Ingo Molnar wrote:
>>     
>>> You seem to dismiss that angle by calling my arguments bullshit, but 
>>> i dont know on what basis you dismiss it. Sure, a feature and extra 
>>> complexity _always_ has a robustness cost. If your argument is that 
>>> we should move cpu_clock() to assembly to make it more dependable - 
>>> i'm all for it.
>>>       
>> Umm. cpu_clock() isn't even cross-cpu synchronized, and has actually 
>> thrown away all the information that can make it so, afaik. At least 
>> the comments say "never more than 2 jiffies difference"). You do 
>> realize that if you want to order events across CPU's, we're not 
>> talking about "jiffies" here, we're talking about 50-100 CPU _cycles_.
>>     
>
> Steve got the _worst-case_ cpu_clock() difference down to 60 usecs not 
> so long ago. It might have regressed since then, it's really hard to do 
> it without cross-CPU synchronization.
>
> ( But it's not impossible, as Steve has proven it, because physical time
>   goes on linearly on each CPU so we have a chance to do it: by
>   accurately correlating the GTOD timestamps we get at to-idle/from-idle
>   times to the TSC. )
>
> And note that i'm not only talking about cross-CPU synchronization, i'm 
> also talking about _single CPU_ timestamps. How do you get it right with 
> TSCs via a pure postprocessing method? A very large body of modern CPUs 
> will halt the TSC when they go into idle. (about 70% of the installed 
> base or so)
>
> Note, we absolutely cannot do accurate timings in a pure 
> TSC-post-processing environment: unless you want to trace _every_ 
> to-idle and from-idle event, which can easily be tens of thousands of 
> extra events per seconds.
>
> What we could do perhaps is a hybrid method:
>
>  - save a GTOD+TSC pair at important events, such as to-idle and
>    from-idle, and in the periodic sched_tick(). [ perhaps also save it 
>    when we change cpufreq. ]
>
>  - save the (last_GTOD, _relative_-TSC) pair in the trace entry
>
> with that we have a chance to do good post-processed correlation - at 
> the cost of having 12-16 bytes of timestamp, per trace entry.
>
> Or we could upscale the GTOD to 'TSC time', at go-idle and from-idle. 
> Which is rather complicated with cpufreq - which frequency do we want to 
> upscale to if we have a box with three available frequencies? We could 
> ignore cpufreq altogether - but then there goes dependable tracing on 
> another range of boxes.
>   

The "full timestamp" records should include:

    * absolute tsc
    * absolute monotonic timestamp
    * new tsc freqency

If you then make sure that all the cpufreq/idle/suspend-resume code
emits appropriate records when changing the tsc frequency, then you
should always be able to fully regenerate an absolute timestamp.

If you generate the monotonic timestamp with a good clocksource, then
you should be able to correlate the timestamps between cpus.

Oddly enough, this is identical to the Xen clocksource's use of the tsc ;)

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