From: Andy Whitcroft <apw@shadowen.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Andy Whitcroft <apw@shadowen.org>,
Dave Hansen <haveblue@us.ibm.com>, Bob Picco <bob.picco@hp.com>,
Ingo Molnar <mingo@elte.hu>,
"Martin J. Bligh" <mbligh@mbligh.org>, Andi Kleen <ak@suse.de>,
linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
Linux Memory Management <linux-mm@kvack.org>
Subject: [PATCH 0/3] Zone boundry alignment fixes
Date: Tue, 9 May 2006 12:05:05 +0100 [thread overview]
Message-ID: <exportbomb.1147172704@pinky> (raw)
In-Reply-To: 445DF3AB.9000009@yahoo.com.au
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.
Comments.
-apw
--
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>
next prev parent reply other threads:[~2006-05-09 11:05 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060419112130.GA22648@elte.hu>
[not found] ` <p73aca07whs.fsf@bragg.suse.de>
[not found] ` <20060502070618.GA10749@elte.hu>
[not found] ` <200605020905.29400.ak@suse.de>
[not found] ` <44576688.6050607@mbligh.org>
2006-05-02 14:25 ` assert/crash in __rmqueue() when enabling CONFIG_NUMA Nick Piggin
2006-05-04 1:32 ` Bob Picco
2006-05-04 8:37 ` Ingo Molnar
2006-05-04 9:14 ` Ingo Molnar
2006-05-04 9:26 ` Ingo Molnar
2006-05-04 8:37 ` Andy Whitcroft
2006-05-04 15:21 ` Dave Hansen
2006-05-04 15:46 ` Bob Picco
2006-05-04 16:07 ` Dave Hansen
2006-05-04 19:25 ` Ingo Molnar
2006-05-04 19:43 ` Bob Picco
2006-05-04 21:50 ` Andy Whitcroft
2006-05-05 5:17 ` Ingo Molnar
2006-05-05 13:55 ` Bob Picco
2006-05-05 14:33 ` Dave Hansen
2006-05-05 14:50 ` Bob Picco
2006-05-05 14:57 ` Dave Hansen
2006-05-05 15:03 ` Martin J. Bligh
2006-05-05 16:22 ` Bob Picco
2006-05-05 16:18 ` Bob Picco
2006-05-06 8:32 ` Nick Piggin
2006-05-07 13:07 ` Andy Whitcroft
2006-05-07 13:18 ` Nick Piggin
2006-05-09 11:05 ` Andy Whitcroft [this message]
2006-05-09 11:05 ` [PATCH 1/3] zone init check and report unaligned zone boundries Andy Whitcroft
2006-05-09 11:28 ` Nick Piggin
2006-05-09 11:05 ` [PATCH 2/3] x86 align highmem zone boundries with NUMA Andy Whitcroft
2006-05-09 11:05 ` [PATCH 3/3] zone allow unaligned zone boundries Andy Whitcroft
2006-05-11 7:59 ` [PATCH 0/3] Zone boundry alignment fixes Andrew Morton
2006-05-12 14:19 ` Ingo Molnar
2006-05-13 1:39 ` Nick Piggin
2006-05-18 14:20 ` [PATCH 0/2] Zone boundary alignment fixes cleanups Andy Whitcroft
2006-05-18 14:21 ` [PATCH 1/2] zone init check and report unaligned zone boundaries fix Andy Whitcroft
2006-05-18 14:21 ` [PATCH 2/2] zone allow unaligned zone boundaries spelling fix Andy Whitcroft
2006-05-18 14:49 ` Andy Whitcroft
2006-05-18 15:54 ` [PATCH 0/2] Zone boundary alignment fixes, cleanups v2 Andy Whitcroft
2006-05-18 15:55 ` [PATCH 1/2] zone init check and report unaligned zone boundaries fix Andy Whitcroft
2006-05-18 15:55 ` [PATCH 2/2] zone allow unaligned zone boundaries spelling fix Andy Whitcroft
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=exportbomb.1147172704@pinky \
--to=apw@shadowen.org \
--cc=ak@suse.de \
--cc=akpm@osdl.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=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;
as well as URLs for NNTP newsgroup(s).