linux-kernel - Re: [PATCH 1/2] tracing/function-return-tracer: Make the function return tracer lockless

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 13 Nov 2008 09:55:51 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Frédéric Weisbecker <fweisbec@...il.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH 1/2] tracing/function-return-tracer: Make the function
	return tracer lockless


* Frédéric Weisbecker <fweisbec@...il.com> wrote:

> BTW I'm wondering about consistency in time capturing. When I look 
> into kernel/sched_clock.c I see this in introduction:
> 
> "The clock: sched_clock_cpu() is monotonic per cpu, and should be 
> somewhat consistent between cpus (never more than 2 jiffies 
> difference)."
> 
> Two Jiffies, that could result in a lot of inconsistency in the way 
> of nanosec capturing. The current task can be preempted between the 
> call time and the return time and I'm doing a 
> cpu_clock(raw_smp_processor_id) on these two times. Should I keep 
> the same processor_id for these two captures? But what would happen 
> if this cpu is shut down between these two times? One other solution 
> would be to plan time capture in usec but I would mostly lose the 
> interest of function cost measuring....
> 
> What do you think?

in practice the jitter is much lower - a couple of microseconds - up 
to a few dozen at most.

But it's a possibility, and i think the best solution is something 
that Steve suggested yesterday: a /debug/tracing/trace_options flag 
that turns on global ordering for tracing timestamps. Something like:

  echo global_timestamps > /debug/tracing/trace_options

tracers could also change the default of this flag. The function-cost 
tracer will probably want to default to globally synchronous 
timestamps, while the preempt and irqsoff tracers want to default to 
local timestamps only.

Would something like this work for you?

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