On Friday, December 16, 2005 11:40 pm, Linus Torvalds wrote:
> Side note: there may be hardware cache protocol _scheduling_ reasons
> why some particular hw platform might prefer to go through the
> "Shared" state in their cache protocol.
>
> For example, you might have hardware that otherwise ends up being
> very unfair, where the two-stage lock aquire might actually allow
> another node to come in at all. Fairness and balance often comes at a
> cost, both in hw and in sw.
>
> Arguably such hardware sounds pretty broken, but the point is that
> these things can certainly depend on the platform around the CPU as
> well as on what the CPU itself does.
>
> I'm not saying that that is necessarily what Jesse was arguing about,
> but lock contention behaviour can be "interesting".
Yeah, that's a good point. Getting lock behavior 'just right' can get
pretty platform specific. For instance, on a CMP type machine,
bouncing a lock between CPUs can be nearly free, whereas on a large
directory based machine like the Altix, pretty much any cache line
write (or fake write like ia64's ld.bias) is an expensive operation
since it involves lots of relatively slow network activity.
Jesse
-
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]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
