linux-kernel - Re: [PATCH 1/2 v2] tracing/function-graph-tracer: various fixes and features

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] [day] [month] [year] [list]

Message-ID: <20090126145513.GA9128@elte.hu>
Date:	Mon, 26 Jan 2009 15:55:13 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2 v2] tracing/function-graph-tracer: various fixes
	and features


* Frederic Weisbecker <fweisbec@...il.com> wrote:

> On Fri, Jan 23, 2009 at 12:00:37PM +0100, Ingo Molnar wrote:
> > 
> > * Frédéric Weisbecker <fweisbec@...il.com> wrote:
> > 
> > > > Still needs a solution - if we do cross-CPU traces we want to have a 
> > > > global trace clock with 'seemless' transition between CPUs.
> > > 
> > > So it doesn't only need a monotonic clock. It needs a global consistent 
> > > clock like ktime for example? Unfortunately this one uses seq_locks and 
> > > would add some drawbacks like verifying if the traced function doesn't 
> > > hold the write seq_lock and it will bring some more ftrace recursion...
> > 
> > using ktime_get() is indeed out of question - GTOD callpaths are too 
> > complex (and also too slow).
> > 
> > I'd not change anything in the current logic, but i was thinking of a new 
> > trace_option, which can be set optionally. If that trace option is set 
> > then this bit of ring_buffer_time_stamp():
> > 
> >         time = sched_clock() << DEBUG_SHIFT;
> > 
> > gets turned into:
> > 
> >         time = cpu_clock(cpu) << DEBUG_SHIFT;
> > 
> > This way we default to sched_clock(), but also gain some 'global' 
> > properties if the trace_option is set.
> 
> 
> Ok, yeah that's a good idea.
> 
>  
> > Furthermore, another trace_option could introduce a third 'strongly 
> > ordered' trace-clock variant, which would use cmpxchg and per cpu 
> > timestamps, something like this:
> > 
> > atomic64_t curr_time;
> > 
> > DEFINE_PER_CPU(u64, prev_cpu_time);
> > ...
> > 
> > retry:
> > 	prev_cpu_time = per_cpu(prev_cpu_time, cpu);
> > 	cpu_time = sched_clock();
> > 	old_time = atomic64_read(&curr_time);
> > 
> > 	delta = cpu_time - prev_cpu_time;
> > 	if (unlikely((s64)delta <= 0))
> > 		delta = 1;
> > 
> > 	new_time = old_time + delta;
> > 
> > 	if (atomic64_cmpxchg(&curr_time, old_time, new_time) != new_time)
> > 		goto repeat;
> > 
> >         time = new_time << DEBUG_SHIFT;
> > 
> > This would be a monotonic, global clock wrapped around sched_clock(). It 
> > uses a cmpxchg to achieve it, but we have to use global ordering anyway. 
> > 
> > It would still be _much_ faster than any GTOD clocksource we have.
> > 
> > Hm?
> > 
> 
> And that would be even more faster that cpu_clock().
> 
> But why implement both? Wouldn't the above be more faster while playing 
> the same thing than cpu_clock()

cpu_clock() can be faster than a cmpxchg on a global variable - as 
cpu_clock() does not serialize globally at all as long as each CPU 
observes its own time only.

in any case, these are nuances - we need _some_ trace clock before we 
worry about details like that ;-)

	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/