[lkml]   [2006]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/3] Zone boundry alignment fixes
    Andy Whitcroft <> wrote:
    > Ok. Finally got my test bed working and got this lot tested.
    > To summarise the problem , the buddy allocator currently requires
    > that the boundries between zones occur at MAX_ORDER boundries.
    > The specific case where we were tripping up on this was in x86 with
    > NUMA enabled. There we try to ensure that each node's stuct pages
    > are in node local memory, in order to allow them to be virtually
    > mapped we have to reduce the size of ZONE_NORMAL. Here we are
    > rounding the remap space up to a large page size to allow large
    > page TLB entries to be used. However, these are smaller than
    > MAX_ORDER. This can lead to bad buddy merges. With VM_DEBUG enabled
    > we detect the attempts to merge across this boundry and panic.
    > We have two basic options we can either apply the appropriate
    > alignment when we make make the NUMA remap space, or we can 'fix'
    > the assumption in the buddy allocator. The fix for the buddy
    > allocator involves adding conditionals to the free fast path and
    > so it seems reasonable to at least favor realigning the remap space.
    > Following this email are 3 patches:
    > zone-init-check-and-report-unaligned-zone-boundries -- introduces
    > a zone alignement helper, and uses it to add a check to zone
    > initialisation for unaligned zone boundries,
    > x86-align-highmem-zone-boundries-with-NUMA -- uses the zone alignment
    > helper to align the end of ZONE_NORMAL after the remap space has
    > been reserved, and
    > zone-allow-unaligned-zone-boundries -- modifies the buddy allocator
    > so that we can allow unaligned zone boundries. A new configuration
    > option is added to enable this functionality.
    > The first two are the fixes for alignement in x86, these fix the
    > panics thrown when VM_DEBUG is enabled.
    > The last is a patch to support unaligned zone boundries. As this
    > (re)introduces a zone check into the free hot path it seems
    > reasonable to only enable this should it be needed; for example
    > we never need this if we have a single zone. I have tested the
    > failing system with this patch enabled and it also fixes the panic.
    > I am inclined to suggest that it be included as it very clearly
    > documents the alignment requirements for the buddy allocator.

    There's some possibility here of interaction with Mel's "patchset to size
    zones and memory holes in an architecture-independent manner." I jammed
    them together - let's see how it goes.

    I also fixed the spelling of "boundary" in about 1.5 zillion places ;)
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-05-11 10:05    [W:0.023 / U:102.248 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site