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

From: H. Peter Anvin
Date: Wed Jun 22 2011 - 14:14:11 EST

On 06/22/2011 11:00 AM, Andrew Morton wrote:
> :
> : Second, the BadRAM patch expands the address patterns from the command
> : line into individual entries in the kernel's e820 table. The e820
> : table is a fixed buffer that supports a very small, hard coded number
> : of entries (128). We require a much larger number of entries (on
> : the order of a few thousand), so much of the google kernel patch deals
> : with expanding the e820 table.

This has not been true for a long time.

> I have a couple of thoughts here:
> - If this patchset is merged and a major user such as google is
> unable to use it and has to continue to carry a separate patch then
> that's a regrettable situation for the upstream kernel.
> - Google's is, afaik, the largest use case we know of: zillions of
> machines for a number of years. And this real-world experience tells
> us that the badram patchset has shortcomings. Shortcomings which we
> can expect other users to experience.
> So. What are your thoughts on these issues?

I think a binary structure fed as a linked list data object makes a lot
more sense. We already support feeding e820 entries in this way,
bypassing the 128-entry limitation of the fixed table in the zeropage.

The main issue then is priority; in particular memory marked UNUSABLE
(type 5) in the fed-in e820 map will of course overlap entries with
normal RAM (type 1) information in the native map; we need to make sure
that the type 5 information takes priority.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at