![]() | |||||||||||||
Messages in this thread |
Andrew Morton wrote: > Mel Gorman <mel@csn.ul.ie> 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 would say yes, it is a very low risk patch in my view and provides a very large part of the protections we require. i386 as our largest userbase should be safe from zone/node alignment issues with just this change. Others need slightly more (the page_zone_idx check) which is being discussed in another thread. -apw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-05-22 10:28 [from the cache] ©2003-2008 | |||||||||||||