[lkml]   [2014]   [Dec]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: DRAM unreliable under specific access patern
On Mon 2014-12-29 13:13:17, Jiri Kosina wrote:
> On Wed, 24 Dec 2014, Pavel Machek wrote:
> > Well... We could periodically scrub (every few miliseconds) pages
> > mapped to userspace.
> I.e. implement ECC in software. Would be extremely slow though.

No, not really. If you read the cells that are about to go bad, you'll
update them. Agreed on extremely slow.

> > We might be able to do some magic and disallow cache flushes to
> > userspace programs.
> My understanding is that cflush is not strictly necessary, it only makes
> the issue more likely to trigger.

Umm. Not really, AFAICT.

So, the memory can take "certain ammount" of "neighboring
accesses". You need to do that ammount before next refresh.

> If you modify the pattern so that it neraly fits into cacheline (but not
> really), you would be able to produce similar (if not the same) cache
> eviction pattern as if without explicit cflush. Right?

No, I don't think so.

Well.. you need to generate certain ammount of traffic on the address
lines, and it corrupts "neighboring" cells. I wish I knew more about
DRAM... If you'll read a cache line, you can't "break" it as reads
refreshes it. You need to do few miliseconds worth of reads, AFAICT.

If you'll just keep reading cachelines, the cachelines you read will
not be "neighboring" enough to the "target" cells you want to break.

(cesky, pictures)

 \ /
  Last update: 2014-12-29 18:21    [W:0.045 / U:1.476 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site