Re: [PATCH v2 0/3] support for broken memory modules (BadRAM)

[Craig Bergstrom]

On Fri, Jun 24, 2011 at 1:05 AM, Rick van Rein <rick@xxxxxxxxxxx> wrote:
>
> Hi Craig,
>
> > We (Google) are working on a data-driven answer for this question.  I know
> > that there has been some analysis on this topic on the past, but I don't
> > want to speculate until we've had some time to put all the pieces together.
>
> The easiest way to do this could be to take the algorithm from Memtest86
> and apply it to your data, to see if it finds suitable patterns for the
> cases tried.
>
> By counting bits set to zero in the masks, you could then determine how
> 'tight' they are.  A mask with all-ones covers one memory page; each
> zero bit in the mask (outside of the CPU's page size) doubles the number
> of pages covered.
>
> You can ignore the address over which the mask is applied, although you
> would then be assuming that all the pages covered by the mask are indeed
> filled with RAM.
>
> You would want to add the figures for the different masks.

This seems like a reasonable approach.  I know there was some analysis
done, and I'm doing my best to get the folks who made the original
decision to weigh in.

>
> I am very curious about your findings.  Independently of those, I am in
> favour of a patch that enables longer e820 tables if it has no further
> impact on speed or space.

I think that we'd all be satisfied with a mechanism that allows for
badram to be specified via both command line and an extended e820 map.

>
>
> Cheers,
>  -Rick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/