[lkml]   [2001]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Wow! Is memory ever cheap!
Larry McVoy writes:
> On Wed, May 09, 2001 at 12:24:25AM -0400, Marty Leisner wrote:
> > My understanding is suns big machines stopped using ecc and they
> The SUN problem was a cache problem and there is no way that I believe
> that SUN would turn of ECC in the cache. There are good reasons for
> not doing so. If you think through the end to end argument, you will
> see that you have no way to do checks on the data path into/out of the
> processor. If that part of the datapath is not checked then no amount
> of checking elsewhere does any good, the processor can be corrupting
> your data and never know it. If SUN was so stupid as to remove this,
> then it is a dramatically different place. I heard that there was a
> bug in the cache controller, I never heard that they had removed ECC.

There are issues with error detection/correction/recovery with
different designs of L1 and L2 caches. There's a good paper:

IBM S/390 storage hierarchy - G5 and G6 performance considerations
IBM Journal of Research and Development
Vol 43 No. 5/6
available at

which covers IBM's choice of L1 and L2 design for S/390. The section on
"S/390 reliability and performance implications" is relevant here. In
particular, they use a solution which isn't best from the performance
point of view but ensures you don't discover "too late" about an error.
I heard a rumour (now I get to the unsubstantiated part :-) that Sun
chose a higher-performing design for their cache subsystem but which has
a nastier failure mode in the case of cache errors.


Malcolm Beattie <>
Unix Systems Programmer
Oxford University Computing Services
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:52    [W:0.077 / U:0.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site