[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.121 / U:24.456 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site