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

[Andrew Morton]

Andy Whitcroft <apw@xxxxxxxxxxxx> wrote:
>
> Andrew Morton wrote:
> > Mel Gorman <mel@xxxxxxxxx> 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.
> 

Well I've largely lost the plot here (which happens often), and it appears
that Nick has concerns with this approach (which also is not uncommon).

So could you guys please come to some sort of (rapid) consensus and tell me
which patches from -mm3 (hopefully but an hour away) need to go into
2.6.17?

Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/