By: anon (anon.delete@this.anon.com), September 2, 2012 6:23 pm
Room: Moderated Discussions
Paul A. Clayton (paaronclayton.delete@this.gmail.com) on September 1, 2012 7:29 am wrote:
> 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.)
Didn't Alpha always support 64 KB, in addition to 8 KB, 512 KB, and 2 MB page sizes?
> 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.)
Didn't Alpha always support 64 KB, in addition to 8 KB, 512 KB, and 2 MB page sizes?
Topic | Posted By | Date |
---|---|---|
Article: Haswell TM Alternatives | David Kanter | 2012/08/21 10:17 PM |
Article: Haswell TM Alternatives | Håkan Winbom | 2012/08/22 12:52 AM |
Article: Haswell TM Alternatives | David Kanter | 2012/08/22 02:06 AM |
Article: Haswell TM Alternatives | anon | 2012/08/22 09:46 AM |
Article: Haswell TM Alternatives | Linus Torvalds | 2012/08/22 10:16 AM |
Article: Haswell TM Alternatives | Doug S | 2012/08/24 09:34 AM |
AMD's ASF even more limited | Paul A. Clayton | 2012/08/22 10:20 AM |
AMD's ASF even more limited | Linus Torvalds | 2012/08/22 10:41 AM |
Compiler use of ll/sc? | Paul A. Clayton | 2012/08/28 10:28 AM |
Compiler use of ll/sc? | Linus Torvalds | 2012/09/08 01:58 PM |
Lock recognition? | Paul A. Clayton | 2012/09/10 02:17 PM |
Sorry, I was confused | Paul A. Clayton | 2012/09/13 11:56 AM |
Filter to detect store conflicts | Paul A. Clayton | 2012/08/22 10:19 AM |
Article: Haswell TM Alternatives | bakaneko | 2012/08/22 03:02 PM |
Article: Haswell TM Alternatives | David Kanter | 2012/08/22 03:45 PM |
Article: Haswell TM Alternatives | bakaneko | 2012/08/22 10:56 PM |
Cache line granularity? | Paul A. Clayton | 2012/08/28 10:28 AM |
Cache line granularity? | David Kanter | 2012/08/31 09:13 AM |
A looser definition might have advantages | Paul A. Clayton | 2012/09/01 07:29 AM |
Cache line granularity? | rwessel | 2012/08/31 08:54 PM |
Alpha load locked granularity | Paul A. Clayton | 2012/09/01 07:29 AM |
Alpha load locked granularity | anon | 2012/09/02 06:23 PM |
Alpha pages groups | Paul A. Clayton | 2012/09/03 05:16 AM |
An alternative implementation | Maynard Handley | 2012/11/20 10:52 PM |
An alternative implementation | bakaneko | 2012/11/21 06:52 AM |
Guarding unread values? | Paul A. Clayton | 2012/11/21 09:39 AM |
Guarding unread values? | bakaneko | 2012/11/21 12:25 PM |
TM granularity and versioning | Paul A. Clayton | 2012/11/21 09:27 AM |
TM granularity and versioning | Maynard Handley | 2012/11/21 11:52 AM |
Indeed, TM (and coherence) has devilish details (NT) | Paul A. Clayton | 2012/11/21 11:56 AM |