Re: Efficiency of in-order vs. OoO

EricP wrote:

EricP wrote:

MitchAlsup1 wrote:

Scott Lurndal wrote:
>

mitchalsup@aol.com (MitchAlsup1) writes:

Paul A. Clayton wrote:
>

For memory reads, the late failure generated by an uncorrectable
ECC error would probably have to be handled differently or there
would probably be little opportunity to exploit out-of-order
retirement. It might not be entirely unreasonable to treat such as
a fatal thread error that is asynchronous.

>
What about for memory stores where the ECC check on the delivered data fails ?? This seems to be just as fatal as a LD with an ECC fail.

>

As most stores are posted, the data stored needs to be 'poisoned'
so that any subsequent use of the data (e.g. a load) will report
a fault.

>
Storing the bad <arriving> ECC should take care of that.

 I don't think that will always work. Assuming we are using a
72-bit SECDED ECC and a cache line is read with a double error,
then if the ST overwrites an 8 byte aligned value it will generate
a new valid ECC and correct the error.
 However if the ST is less than 8 bytes or misaligned, it won't know which
of the 8 bytes was invalid so can't tell if the bad data was overwritten.
If it keeps the old ECC as an error indicator, that code might actually be
correct for the new data. If it generates a new valid ECC then it loses
track of the fact that the data MAY be invalid.
 In this second case of partial overwrite I think it has to generate a
new invalid ECC for the new 8 byte data indicating a double error.
 When the modified line is written back to DRAM it retains the
double error ECC.

And if the page is out swapped and recycled we lose track of
the error indicator on that 8-byte value.

The line was displaced from an L1/L2 cache and its DRAM landing spot is
not in DRAM ?? but over on some disk/SSD ?!? How (the frick) did it get into L1/L2 if it was not in DRAM ?? and thus
not on disk (as its only access point). ????