[lkml]   [2011]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH v2 0/3] support for broken memory modules (BadRAM)
    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.


     \ /
      Last update: 2011-06-22 20:17    [W:0.019 / U:8.096 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site