Re: [PATCH 1/2] Align the node_mem_map endpoints to a MAX_ORDER boundary

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 19 May 2006, Andrew Morton wrote:

Mel Gorman <[email protected]> wrote:

Andy added code to buddy allocator which does not require the zone's
endpoints to be aligned to MAX_ORDER. An issue is that the buddy
allocator requires the node_mem_map's endpoints to be MAX_ORDER aligned.
Otherwise __page_find_buddy could compute a buddy not in node_mem_map for
partial MAX_ORDER regions at zone's endpoints. page_is_buddy will detect
that these pages at endpoints are not PG_buddy (they were zeroed out by
bootmem allocator and not part of zone). Of course the negative here is
we could waste a little memory but the positive is eliminating all the
old checks for zone boundary conditions.

SPARSEMEM won't encounter this issue because of MAX_ORDER size constraint
when SPARSEMEM is configured. ia64 VIRTUAL_MEM_MAP doesn't need the
logic either because the holes and endpoints are handled differently.
This leaves checking alloc_remap and other arches which privately allocate
for node_mem_map.

Do we think we need this in 2.6.17?


I think so. Not all architectures are making sure their node_start_pfn is aligned to a boundary. For example, x86_64 does, ia64 may align depending on the value of MAX_ORDER and i386 does not appear to make any effort. No one seems to be making any special effort to align the end of the zone at all. This potentially means that the buddy allocator is checking portions of memory as if they were struct page * when they are something totally different. I suspect it's just luck that the memory outside of the mem_map never looked like buddies.

Anyone else care to comment?

--
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux