By: anonymou5 (no.delete@this.spam.com), September 16, 2022 4:50 pm
Room: Moderated Discussions
hobold (hobold.delete@this.vectorizer.org) on September 16, 2022 1:03 pm wrote:
> groo (charlie.delete@this.semiaccurate.com) on September 16, 2022 11:06 am wrote:
>
> > It takes time to compute ECC data and L1s tend to be a bit tight on timings.
>
> ECC computations might not have to be in the critical path. For example a load operation
> could forward its data without ECC check; sometime later you'd do the ECC computations;
> at the retire stage you would verify that the data and ECC codes match. On mismatch you'd
> have to replay from the erroneous load forward, possibly with a corrected error.
>
> Obviously, bit errors would have to be really rare for this to make sense. If the goal is to
> get higher yield with more redundancy in the L1 cache, then ECC errors are expected to be a
> somewhat common occurrence, and this suggested scheme probably costs too much performance.
Ah yes, more "let me speculate ahead" stuff. Which has gone so damn well for us all.
Hear that faint giggle? That is Spectre, sitting in its dark corner, waiting for you.
"But this is different." I hear you say. "Since it's not under the attacker's control."
"Uhm... you just haven thought it through enough. Please stay away from CPU design."
...
Please take the above with good humor. I'm simply trying to point out how hard this is.
If it were easy, we'd be done with it by now. But, alas, we're not. Spectre is hard to
eliminate. And even though we have managed to stomp out a few instances of it, others
have crept into the designs since 2017/2018. Precisely because designers still are not
thinking things through. More humility and more 🍊 needed. :)
> groo (charlie.delete@this.semiaccurate.com) on September 16, 2022 11:06 am wrote:
>
> > It takes time to compute ECC data and L1s tend to be a bit tight on timings.
>
> ECC computations might not have to be in the critical path. For example a load operation
> could forward its data without ECC check; sometime later you'd do the ECC computations;
> at the retire stage you would verify that the data and ECC codes match. On mismatch you'd
> have to replay from the erroneous load forward, possibly with a corrected error.
>
> Obviously, bit errors would have to be really rare for this to make sense. If the goal is to
> get higher yield with more redundancy in the L1 cache, then ECC errors are expected to be a
> somewhat common occurrence, and this suggested scheme probably costs too much performance.
Ah yes, more "let me speculate ahead" stuff. Which has gone so damn well for us all.
Hear that faint giggle? That is Spectre, sitting in its dark corner, waiting for you.
"But this is different." I hear you say. "Since it's not under the attacker's control."
"Uhm... you just haven thought it through enough. Please stay away from CPU design."
...
Please take the above with good humor. I'm simply trying to point out how hard this is.
If it were easy, we'd be done with it by now. But, alas, we're not. Spectre is hard to
eliminate. And even though we have managed to stomp out a few instances of it, others
have crept into the designs since 2017/2018. Precisely because designers still are not
thinking things through. More humility and more 🍊 needed. :)
