linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Andy Whitcroft <apw@shadowen.org>
Cc: mel@csn.ul.ie, nickpiggin@yahoo.com.au, haveblue@us.ibm.com,
	ak@suse.de, bob.picco@hp.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, mingo@elte.hu, mbligh@mbligh.org
Subject: Re: [PATCH 1/2] Align the node_mem_map endpoints to a MAX_ORDER boundary
Date: Mon, 22 May 2006 01:44:04 -0700	[thread overview]
Message-ID: <20060522014404.48e57958.akpm@osdl.org> (raw)
In-Reply-To: <44717564.50607@shadowen.org>

Andy Whitcroft <apw@shadowen.org> wrote:
>
> 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.
> 

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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2006-05-22  8:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-19 13:42 [PATCH 0/2] Fixes for node alignment and flatmem assumptions Mel Gorman
2006-05-19 13:43 ` [PATCH 1/2] Align the node_mem_map endpoints to a MAX_ORDER boundary Mel Gorman
2006-05-19 20:49   ` Andrew Morton
2006-05-19 23:25     ` Mel Gorman
2006-05-22  8:25     ` Andy Whitcroft
2006-05-22  8:44       ` Andrew Morton [this message]
2006-05-19 13:43 ` [PATCH 2/2] FLATMEM relax requirement for memory to start at pfn 0 Mel Gorman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060522014404.48e57958.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=ak@suse.de \
    --cc=apw@shadowen.org \
    --cc=bob.picco@hp.com \
    --cc=haveblue@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mbligh@mbligh.org \
    --cc=mel@csn.ul.ie \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox