Re: [PATCH] optimize writer path in time_interpolator_get_counter()

[Christoph Lameter]

On Tue, 2 Aug 2005 tony.luck@xxxxxxxxx wrote:

> Sadly, running my test case (running 1-4 tasks, each bound to a cpu, each pounding
> on gettimeofday(2)) I'm still seeing significant time spent spinning in this loop.
> Things are better: worst case time was down to just over 2ms from 34ms ... which
> is a significant improvement ... but 2ms still sounds ugly.

I think we should be happy about this. Sounds ok for the problematic 
hardware.

> 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.

> So this is a very half-hearted ACK for the patch.  It does improve things, but I
> still think that code that does:
> 
> 	do {
> 		val = xxx;
> 
> 		// execute some stuff here
> 	} while (cmpxchg(&xxx, val, newval) != val);
> 
> is badly flawed.  If this were in some rare code path that was only likely to see
> collisions when more than three planets were aligned, then it might be OK, but this
> is a common path and it is easy for (malicious) users to force multiple cpus into
> running this code ... making it likely that the cmpxchg will fail repeatedly.

cmpxchg is the best that one can do in this case. If you would take a 
spinlock then we would even need more processing.

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. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/