The patch titled
x86_64: Fix memory hotadd heuristics
has been added to the -mm tree. Its filename is
x86_64-fix-memory-hotadd-heuristics.patch
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this
From: "Andi Kleen" <ak@xxxxxxx>
- Set hotadd_percent to 0 by default. This means anybody using hotadd
memory needs to specify the value on the command line. That's because there
are lots of Intel boxes which have a bogus hotplug area in their SRAT and
they would waste a lot of memory before.
- Fix calculation of how much memory to use when the hotplug area exceeds
hotadd_percent
- Fix fallback when the
- Fix fallback if memory hotadd is not compiled in.
This fixes some boot failures on Dell and Unisys systems with memory hotadd
added.
Signed-off-by: Andi Kleen <ak@xxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
---
arch/x86_64/mm/srat.c | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
diff -puN arch/x86_64/mm/srat.c~x86_64-fix-memory-hotadd-heuristics arch/x86_64/mm/srat.c
--- devel/arch/x86_64/mm/srat.c~x86_64-fix-memory-hotadd-heuristics 2006-05-15 21:43:21.000000000 -0700
+++ devel-akpm/arch/x86_64/mm/srat.c 2006-05-15 21:43:21.000000000 -0700
@@ -34,7 +34,10 @@ static nodemask_t nodes_found __initdata
static struct bootnode nodes[MAX_NUMNODES] __initdata;
static struct bootnode nodes_add[MAX_NUMNODES] __initdata;
static int found_add_area __initdata;
-int hotadd_percent __initdata = 10;
+int hotadd_percent __initdata = 0;
+#ifndef RESERVE_HOTADD
+#define hotadd_percent 0 /* Ignore all settings */
+#endif
static u8 pxm2node[256] = { [0 ... 255] = 0xff };
/* Too small nodes confuse the VM badly. Usually they result
@@ -103,6 +106,7 @@ static __init void bad_srat(void)
int i;
printk(KERN_ERR "SRAT: SRAT not used.\n");
acpi_numa = -1;
+ found_add_area = 0;
for (i = 0; i < MAX_LOCAL_APIC; i++)
apicid_to_node[i] = NUMA_NO_NODE;
for (i = 0; i < MAX_NUMNODES; i++)
@@ -154,7 +158,8 @@ acpi_numa_processor_affinity_init(struct
int pxm, node;
if (srat_disabled())
return;
- if (pa->header.length != sizeof(struct acpi_table_processor_affinity)) { bad_srat();
+ if (pa->header.length != sizeof(struct acpi_table_processor_affinity)) {
+ bad_srat();
return;
}
if (pa->flags.enabled == 0)
@@ -191,15 +196,17 @@ static int hotadd_enough_memory(struct b
allowed = (end_pfn - e820_hole_size(0, end_pfn)) * PAGE_SIZE;
allowed = (allowed / 100) * hotadd_percent;
if (allocated + mem > allowed) {
+ unsigned long range;
/* Give them at least part of their hotadd memory upto hotadd_percent
It would be better to spread the limit out
over multiple hotplug areas, but that is too complicated
right now */
if (allocated >= allowed)
return 0;
- pages = (allowed - allocated + mem) / sizeof(struct page);
+ range = allowed - allocated;
+ pages = (range / PAGE_SIZE);
mem = pages * sizeof(struct page);
- nd->end = nd->start + pages*PAGE_SIZE;
+ nd->end = nd->start + range;
}
/* Not completely fool proof, but a good sanity check */
addr = find_e820_area(last_area_end, end_pfn<<PAGE_SHIFT, mem);
_
Patches currently in -mm which might be from ak@xxxxxxx are
x86_64-check-for-bad-dma-address-in-b44-1gb-dma-workaround.patch
x86_64-dont-warn-for-overflow-in-nommu-case-when-dma_mask-is-32bit.patch
i386-x86_64-force-pci=noacpi-on-hp.patch
x86_64-fix-memory-hotadd-heuristics.patch
x86_64-dont-schedule-on-exception.patch
git-acpi.patch
git-agpgart.patch
x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions-x86-fix.patch
x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions-x86-fix-fix.patch
x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions-x86-fix-fix-fix.patch
x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions-x86_64-fix.patch
x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions-x86_64-fix-fix.patch
x86_64-mm-serialize-assign_irq_vector-use-of-static-variables-fix.patch
-
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
