>> I'm still seeing the asymmetric behavior where cpu3 sees the really high >> times, >> while cpu0,1,2 are seeing peaks of 170us, which is still not pretty. > >Is this an SMP system? Updates are performed by cpu0 and therefore the >cacheline is mostly exclusively owned by that processor and then later >forced to become shared by processors 1,2,3.
Yes this is an SMP system (Intel Tiger4). Cpu0 is the boot cpu, and is indeed the one that takes the write lock, and thus the fast-return from the get_counter() code. I'm just very confused as to why I only see these 10X worse outliers on cpu3. There doesn't seem to be anything special about it (/proc/interrupts shows similar stuff happening on each cpu). >We can still switch on the nojitter by default if the ITC's are guaranteed >to be properly synchronized which will make all this ugliness go away. What do you mean by "properly synchronized"? We can't get them completely in step ... but we do know that they are very close. Closer than the microsecond granularity that most users (gettimeofday) are going to pass back to the caller. But running with "nojitter" will occasionally result in time (as seen on two different processors) sometimes jumping back by a microsecond. How bad is this in practice? I can see that a user that simply subtracts two times may sometimes see an answer of minus one micro-second ... but does this hurt? -Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
