David Kanter (dkanter.delete@this.realworldtech.com) on August 31, 2012 9:13 am wrote:
> Paul A. Clayton (paaronclayton.delete@this.gmail.com) on
> August 28, 2012 10:28 am wrote:
>> I wonder if defining the granularity for RTM to be cache
>> line size is appropriate.
>
> There's really no other way to make things work efficiently.
> You already have tags for each line, so why not just add a
> bit or two?

Since a cache line can be smaller than a cache sector (the indexed and tagged chunk), the use of cache line granularity is more flexible than I initially thought (I did discover this fact before my earlier posting however). Even so, it might be attractive to monitor some memory locations at finer granularity.

Architecturally speaking, it also seems a little risky to define one microarchitectural feature as equal to another (even if all reasonable implementations one can think of guarantee this equality). If the risk is small enough, the greater simplicity could justify the decision; but MONITOR/MWAIT already provides a size (range) which seems conceptually closer (than cache line size) to TM monitoring size.

By architecturally defining a range of granularity (similar to MONITOR/MWAIT), implementers would have greater freedom (and, for TM, there would not seem to be any significant software issues). It might be slightly easier to allow two transactions to be simultaneous than to technically order them (even if a "yoctosecond" apart) when they do not conflict within a finer granularity than a cache line (but do conflict at cache line granularity). (Admittedly, supporting ordering would be much more broadly useful, especially since finer-grained non-conflicts--with cache-line conflicts--would tend to be relatively rare.)

However, I do not see any disadvantages to using a range, and I assume Intel had a reason for supporting a range for MONITOR/MWAIT (which has similar coherence issues).