Alpha load locked granularity

Article: Haswell Transactional Memory Alternatives
By: Paul A. Clayton (paaronclayton.delete@this.gmail.com), September 1, 2012 7:29 am
Room: Moderated Discussions
rwessel (robertwessel.delete@this.yahoo.com) on August 31, 2012 8:54 pm wrote:
> Paul A. Clayton (paaronclayton.delete@this.gmail.com) on
> August 28, 2012 10:28 am wrote:
[snip]
>> (The Alpha architectural suggestion for portability of not
>> placing two atomic operands within the same 8 KiB page seems
>> a bit excessive.)
[snip]
> While it might have been changed subsequently, the original
> Alpha architectural suggestion was that such items be quadword
> aligned and in their own "large cache block", which were defined as "likely
> be(ing) 32, 64, 128 or 256 bytes".

I seem to have misinterpreted a statement in version 4 (1998) of the Alpha Architecture Handbook--"A processor’s locked range is the aligned block of 2**N bytes that includes the locked_physical_address. The 2**N value is implementation dependent. It is at least 16 (minimum lock range is an aligned 16-byte block) and is at most the page size for that implementation (maximum lock range is one physical
page)."--and did not remember another statement just a page later--"Hardware implementations are encouraged to lock no more than 128 bytes. Software implementations are encouraged to separate locked locations by at least 128 bytes from
other locations that could potentially be written by another processor while the first location is locked."

It seems Alpha did settle on a single "recommended" number, though I think allowing for page-sized granularity might be excessive. (An implementation could--at some complexity cost--still use primarily page-sized coherence while supporting a finer granularity for LLDx_L/STx_C, though 8KiB seems excessively large for the common coherence granularity.)

(Of course, Alpha did eventually support 64 KiB base pages.)
< Previous Post in ThreadNext Post in Thread >
TopicPosted ByDate
Article: Haswell TM AlternativesDavid Kanter08/21/12 10:17 PM
  Article: Haswell TM AlternativesHåkan Winbom08/22/12 12:52 AM
    Article: Haswell TM AlternativesDavid Kanter08/22/12 02:06 AM
  Article: Haswell TM Alternativesanon08/22/12 09:46 AM
    Article: Haswell TM AlternativesLinus Torvalds08/22/12 10:16 AM
      Article: Haswell TM AlternativesDoug S08/24/12 09:34 AM
    AMD's ASF even more limitedPaul A. Clayton08/22/12 10:20 AM
      AMD's ASF even more limitedLinus Torvalds08/22/12 10:41 AM
        Compiler use of ll/sc?Paul A. Clayton08/28/12 10:28 AM
          Compiler use of ll/sc?Linus Torvalds09/08/12 01:58 PM
            Lock recognition?Paul A. Clayton09/10/12 02:17 PM
              Sorry, I was confusedPaul A. Clayton09/13/12 11:56 AM
  Filter to detect store conflictsPaul A. Clayton08/22/12 10:19 AM
  Article: Haswell TM Alternativesbakaneko08/22/12 03:02 PM
    Article: Haswell TM AlternativesDavid Kanter08/22/12 03:45 PM
      Article: Haswell TM Alternativesbakaneko08/22/12 10:56 PM
  Cache line granularity?Paul A. Clayton08/28/12 10:28 AM
    Cache line granularity?David Kanter08/31/12 09:13 AM
      A looser definition might have advantagesPaul A. Clayton09/01/12 07:29 AM
    Cache line granularity?rwessel08/31/12 08:54 PM
      Alpha load locked granularityPaul A. Clayton09/01/12 07:29 AM
        Alpha load locked granularityanon09/02/12 06:23 PM
          Alpha pages groupsPaul A. Clayton09/03/12 05:16 AM
  An alternative implementationMaynard Handley11/20/12 10:52 PM
    An alternative implementationbakaneko11/21/12 06:52 AM
      Guarding unread values?Paul A. Clayton11/21/12 09:39 AM
        Guarding unread values?bakaneko11/21/12 12:25 PM
    TM granularity and versioningPaul A. Clayton11/21/12 09:27 AM
      TM granularity and versioningMaynard Handley11/21/12 11:52 AM
        Indeed, TM (and coherence) has devilish details (NT)Paul A. Clayton11/21/12 11:56 AM
Reply to this Topic
Name:
Email:
Topic:
Body: No Text
How do you spell blue?