Re: [patch 9/9] Make use of the Master Timer

On Thursday 01 February 2007 15:29, Jiri Bohac wrote: > If I do: > rdtscll(a) > ... > rdtscll(b) > is it guaranteed that (b > a) ? It's not architecturally -- unless you have a barrier. On P4 the micro architecture guarantees it, but there the barrier in get_cycles_sync is pat

Re: [patch 9/9] Make use of the Master Timer

> > Hmm, I wasn't sure. Why is it needed? How outdated can the > > result of RDTSC / RDTSCP be? > > > > If I do: > > rdtscll(a) > > ... > > rdtscll(b) > > is it guaranteed that (b > a) ? > > On a single CPU this is always guaranteed. Even on AMD. It's not guaranteed on Intel at leas

Re: [patch 9/9] Make use of the Master Timer

On Thu, Feb 01, 2007 at 03:29:31PM +0100, Jiri Bohac wrote: > On Thu, Feb 01, 2007 at 12:36:05PM +0100, Andi Kleen wrote: > > On Thursday 01 February 2007 11:00, [EMAIL PROTECTED] wrote: > > > > > + case VXTIME_TSC: > > > + rdtscll(tsc); > > > > Where is the CPU synchroniz

Re: [patch 9/9] Make use of the Master Timer

On Thu, Feb 01, 2007 at 12:36:05PM +0100, Andi Kleen wrote: > On Thursday 01 February 2007 11:00, [EMAIL PROTECTED] wrote: > > > + case VXTIME_TSC: > > + rdtscll(tsc); > > Where is the CPU synchronization? > > > + cpu = smp_processor_id(); > > + rdtscll(t); > >

Re: [patch 9/9] Make use of the Master Timer

On Thursday 01 February 2007 11:00, [EMAIL PROTECTED] wrote: > + case VXTIME_TSC: > + rdtscll(tsc); Where is the CPU synchronization? > + cpu = smp_processor_id(); > + rdtscll(t); Also no synchronization. It's slower, but needed. > unsigned long long s

[patch 9/9] Make use of the Master Timer

Make use of the whole Master Timer infrastructure in gettimeofday, monotonic_clock, etc. Also make the vsyscall version of gettimeofday use the guess_mt() if possible. Signed-off-by: Jiri Bohac <[EMAIL PROTECTED]> Index: linux-2.6.20-rc5/arch/x86_64/kernel/time.c ===