I wonder if defining the granularity for RTM to be cache line size is appropriate.

Such would seem to significantly constrain the implementation of finer-grained monitoring. An implementation could monitor at a finer granularity, mainly avoiding some data communication latency, as long as a single order of atomic actions could be guaranteed; but architecturally allowing (but not requiring) finer-grained monitoring might modestly simplify hardware that exploits lack of access-grained conflict.

There does not appear to be much, if any, semantic difference between fine-grained and cache-line granular monitoring since for any collection of transactions that do not conflict at access-level granularity, any ordering of these transactions will be acceptable. (Because hardware could be clever in avoiding transaction failures, it seems that portable software [i.e., working with extremely clever and with simple implementations with the same cache line size] could not even use such to observe the density of "conflicts".)

I wonder if using monitor-line size (introduced for MONITOR/MWAIT)--or something like it--would be better. The monitor-line size includes a minimum and maximum size. Such a range would seem to allow greater freedom of implementation. Alternatively, an architectural minimum size might be defined as the specific access size (which is the minimum required for transactional semantics) and the maximum size might be defined as the cache line size.

Using the cache line size does have the minor annoyance that performance portability becomes more difficult. (The Alpha architectural suggestion for portability of not placing two atomic operands within the same 8 KiB page seems a bit excessive.) Fixing the maximum "monitor-line" size at 64 bytes might not be unreasonable in order to simplify portable software.

By the way, it was interesting to read that Intel (for x86, at least) defines a cache line as being a subset of a cache sector. (I am used to the reverse use of the terms.)