[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4ABB6C3A.8070109@kernel.org>
Date: Thu, 24 Sep 2009 21:55:22 +0900
From: Tejun Heo <tj@...nel.org>
To: Linux Kernel <linux-kernel@...r.kernel.org>,
David Miller <davem@...emloft.net>,
Rusty Russell <rusty@...tcorp.com.au>,
Christoph Lameter <cl@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>
Subject: [PATCH 1/3] percpu: make pcpu_build_alloc_info() clear static buffers
pcpu_build_alloc_info() may be called multiple times when percpu is
falling back to different first chunk allocator. Make it clear static
buffers so that they don't contain values from previous runs.
Signed-off-by: Tejun Heo <tj@...nel.org>
---
These three patches are scheduled for mainline and aim to work around
the cases where distance between the two farthest units is too large
compared to vmalloc area size. This happens on sparc64 because
vmalloc area size is relatively small there and nodes can easily be
placed such that they are too far apart.
This patchset implements page mapping first chunk allocator for
sparc64 and make embedding allocator fallback to it when vmalloc area
doesn't seem large enough. This should make percpu allocator more
robust on other archs which implement page mapping allocator (only x86
currently) and diagnosing problems easier on other archs.
Thanks.
mm/percpu.c | 4 ++++
1 file changed, 4 insertions(+)
Index: work/mm/percpu.c
===================================================================
--- work.orig/mm/percpu.c
+++ work/mm/percpu.c
@@ -1347,6 +1347,10 @@ struct pcpu_alloc_info * __init pcpu_bui
struct pcpu_alloc_info *ai;
unsigned int *cpu_map;
+ /* this function may be called multiple times */
+ memset(group_map, 0, sizeof(group_map));
+ memset(group_cnt, 0, sizeof(group_map));
+
/*
* Determine min_unit_size, alloc_size and max_upa such that
* alloc_size is multiple of atom_size and is the smallest
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists