On Tue, 2 Aug 2005 [email protected] 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |