in reply to OT: Solaris expertise?

This is less Solaris and more (Ultra)SPARC architecture, and that paper discusses some "OS" I've never heard of, "NetraDPS". I found some UltraSparc CPU documentation, but it is somewhat vague on the memory accesses issued by a CASX (or CASXA) instruction.

My vague interpretation of D.2.5.3 is that a CASX instruction will fetch the appropriate page into L2 cache if it is not already there, and then perform the exchange only in the L2 cache, and not force an immediate write-back to the main RAM. This somewhat matches the error behaviour from 16.9.1.7, where a conflict between ECC corrections and CASX instructions on writeback may occur.

Replies are listed 'Best First'.
Re^2: OT: Solaris expertise?
by BrowserUk (Patriarch) on Sep 28, 2011 at 10:28 UTC
    My vague interpretation of D.2.5.3 is that a CASX instruction will fetch the appropriate page into L2 cache if it is not already there, and then perform the exchange only in the L2 cache, and not force an immediate write-back to the main RAM.

    Thank you for the link and your interpretation. It still took a while for the penny to drop, but it has now.

    On the T1 & T2, L1 (instruction & data) caches are per core. The L2 cache is shared between all cores. Compare & swap instructions are specifically designed for intra-thread & intra-core signalling, they therefore have to be coherent at the L2 cache.

    The L2 cache coherency requirement is what causes their high latency; that they only affect a single L2 cache line, their low impact; thus making them perfect for the task of reducing spin-lock 'burn'.

    Now to seek out the equivalent X64 instruction :)

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom