Re: [RFC 4/7] mm: add page consistency checker implementation

["David Hildenbrand (Arm)" <david@kernel.org>]

>> But the real question is: how far away do these bits have to be in memory to be
>> considered "independent" and not prone to the same corruption?
>>
>> 1 bit?
>> 1 byte?
>> 64 byte?
>> 4096 byte?
>> ???
> 
> The notes I have from the research side of things (which should be taken with a
> grain of salt) are something along the lines of:
> 
>  - ~79% are a single bit corruption
>  - ~9% are row faults, so multiple bit corruption within ~8kb
>  - ~4% are bank faults, so multiple bit corruption within ~512mb

Interesting numbers, thanks! What are the other missing %?

> 
> Obviously the numbers would be very different depending on usecase, hardware,
> physical location (did you know bits are more likely to flip in higher
> altitudes?)...

Yeah, heavy cosmic ray apparently makes the problem worse.

The 512mb case is obviously tricky to handle (and is very hw dependent).

Placing bits at least two pages apart could be done more easily.

> 
>> "Embedding both in page_ext means a single fault could
>> corrupt both the tracking data and its redundant copy in the same
>> allocation region."
>>
>> I might be wrong, but isn't that the case for any such fault, as you don't 100%
>> know how the DIMM is organized internally?
>>
>> Do we really expect that a MCE event would, for example, very likely corrupt two
>> neighboring bits, or two bits in the same byte etc? What are the odds that we
>> care?
> 
> For something like a datacenter deployment I'd agree with you - the odds are
> too low to care. For an unsupervised self driving vehicle, where there's no
> human (locally or remotely) available to take over, I'd like the odds to be as
> low as possible :)

I thought that people usually use special RT OSes (with proven logic etc) for
any safety-related systems. Using Linux on the core safety system sounds ... scary.

But, I'd expect corruption of other data (user pages? page tables?) a much
bigger problem than page al locator metdata? What am I missing that this here is
-- in context of the bigger problems there -- a thing we particularly care about?

-- 
Cheers,

David