* linux-next: build failure after merge of the final tree (slab tree related)
@ 2013-08-14 7:53 Stephen Rothwell
0 siblings, 0 replies; 20+ messages in thread
From: Stephen Rothwell @ 2013-08-14 7:53 UTC (permalink / raw)
To: Pekka Enberg, Christoph Lameter; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2980 bytes --]
Hi all,
After merging the final tree, today's linux-next build (powerpc
allnoconfig) failed like this:
In file included from include/linux/xattr.h:14:0,
from include/linux/cgroup.h:21,
from include/linux/memcontrol.h:22,
from include/linux/swap.h:8,
from include/linux/suspend.h:4,
from arch/powerpc/kernel/asm-offsets.c:24:
include/linux/slab.h:587:21: error: redefinition of 'kmalloc_node'
static inline void *kmalloc_node(size_t size, gfp_t flags, int node)
^
include/linux/slab.h:429:30: note: previous definition of 'kmalloc_node' was here
static __always_inline void *kmalloc_node(size_t size, gfp_t flags, int node)
^
include/linux/slab.h:592:21: error: redefinition of '__kmalloc_node'
static inline void *__kmalloc_node(size_t size, gfp_t flags, int node)
^
In file included from include/linux/xattr.h:14:0,
from include/linux/cgroup.h:21,
from include/linux/memcontrol.h:22,
from include/linux/swap.h:8,
from include/linux/suspend.h:4,
from arch/powerpc/kernel/asm-offsets.c:24:
include/linux/slab.h:302:30: note: previous definition of '__kmalloc_node' was here
static __always_inline void *__kmalloc_node(size_t size, gfp_t flags, int node)
^
In file included from include/linux/xattr.h:14:0,
from include/linux/cgroup.h:21,
from include/linux/memcontrol.h:22,
from include/linux/swap.h:8,
from include/linux/suspend.h:4,
from arch/powerpc/kernel/asm-offsets.c:24:
include/linux/slab.h:599:21: error: redefinition of 'kmem_cache_alloc_node'
static inline void *kmem_cache_alloc_node(struct kmem_cache *cachep,
^
In file included from include/linux/xattr.h:14:0,
from include/linux/cgroup.h:21,
from include/linux/memcontrol.h:22,
from include/linux/swap.h:8,
from include/linux/suspend.h:4,
from arch/powerpc/kernel/asm-offsets.c:24:
include/linux/slab.h:307:30: note: previous definition of 'kmem_cache_alloc_node' was here
static __always_inline void *kmem_cache_alloc_node(struct kmem_cache *s, gfp_t flags, int node)
^
Probably caused by commit 1a1d0328975f ("mm/sl[aou]b: Move kmalloc_node
functions to common code") from the slab tree.
This build has CONFIG_NUMA and CONFIG_SLOB undefined.
I have reverted that commit and commits eab6f38ab23c ("mm/sl[aou]b: Move
kmalloc definitions to slab.h"), c8f12ea82f92 ("sl[aou]b: Remove
unnecessary #includes") and 8876832d0466 ("slub: remove
verify_mem_not_deleted()") that followed it.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linux-next: build failure after merge of the final tree (slab tree related)
2010-08-26 14:41 ` Christoph Lameter
@ 2010-08-26 18:16 ` Pekka Enberg
0 siblings, 0 replies; 20+ messages in thread
From: Pekka Enberg @ 2010-08-26 18:16 UTC (permalink / raw)
To: Christoph Lameter
Cc: David Rientjes, Stephen Rothwell, linux-next, linux-kernel, Tejun Heo
On 26.8.2010 17.41, Christoph Lameter wrote:
> On Wed, 25 Aug 2010, David Rientjes wrote:
>
>> I'm really hoping that we can remove this hack soon when the percpu
>> allocator can handle these allocations on UP without any specialized slab
>> behavior.
>
> So do I. Here is a slightly less hacky version through using
> kmalloc_large instead:
Applied and queued to -next.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linux-next: build failure after merge of the final tree (slab tree related)
2010-08-26 3:16 ` David Rientjes
@ 2010-08-26 14:41 ` Christoph Lameter
2010-08-26 18:16 ` Pekka Enberg
0 siblings, 1 reply; 20+ messages in thread
From: Christoph Lameter @ 2010-08-26 14:41 UTC (permalink / raw)
To: David Rientjes
Cc: Pekka Enberg, Stephen Rothwell, linux-next, linux-kernel, Tejun Heo
On Wed, 25 Aug 2010, David Rientjes wrote:
> I'm really hoping that we can remove this hack soon when the percpu
> allocator can handle these allocations on UP without any specialized slab
> behavior.
So do I. Here is a slightly less hacky version through using
kmalloc_large instead:
Subject: Slub: UP bandaid
Since the percpu allocator does not provide early allocation in UP
mode (only in SMP configurations) use __get_free_page() to improvise
a compound page allocation that can be later freed via kfree().
Compound pages will be released when the cpu caches are resized.
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Christoph Lameter <cl@linux.com>
---
mm/slub.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
Index: linux-2.6/mm/slub.c
===================================================================
--- linux-2.6.orig/mm/slub.c 2010-08-26 09:19:35.000000000 -0500
+++ linux-2.6/mm/slub.c 2010-08-26 09:36:29.000000000 -0500
@@ -2103,8 +2103,24 @@ init_kmem_cache_node(struct kmem_cache_n
static inline int alloc_kmem_cache_cpus(struct kmem_cache *s)
{
+#ifdef CONFIG_SMP
+ /*
+ * Will use reserve that does not require slab operation during
+ * early boot.
+ */
BUILD_BUG_ON(PERCPU_DYNAMIC_EARLY_SIZE <
SLUB_PAGE_SHIFT * sizeof(struct kmem_cache_cpu));
+#else
+ /*
+ * Special hack for UP mode. allocpercpu() falls back to kmalloc
+ * operations. So we cannot use that before the slab allocator is up
+ * Simply get the smallest possible compound page. The page will be
+ * released via kfree() when the cpu caches are resized later.
+ */
+ if (slab_state < UP)
+ s->cpu_slab = (__percpu void *)kmalloc_large(PAGE_SIZE << 1, GFP_NOWAIT);
+ else
+#endif
s->cpu_slab = alloc_percpu(struct kmem_cache_cpu);
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linux-next: build failure after merge of the final tree (slab tree related)
2010-08-25 13:50 ` Christoph Lameter
@ 2010-08-26 8:35 ` Tejun Heo
0 siblings, 0 replies; 20+ messages in thread
From: Tejun Heo @ 2010-08-26 8:35 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Stephen Rothwell, linux-next, linux-kernel
Hello,
On 08/25/2010 03:50 PM, Christoph Lameter wrote:
> Can we just get rid of the special UP case and just run the percpu
> subsystem even for UP?
Yeah, maybe. Then we also can guarantee that percpu allocator always
honors alignment (which wq code currently requires and papers over
with similarly ugly workaround). It would add a mostly redundant
allocator code tho. I'll look into how easily it can be done.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linux-next: build failure after merge of the final tree (slab tree related)
2010-08-26 1:35 ` Christoph Lameter
@ 2010-08-26 3:16 ` David Rientjes
2010-08-26 14:41 ` Christoph Lameter
0 siblings, 1 reply; 20+ messages in thread
From: David Rientjes @ 2010-08-26 3:16 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Stephen Rothwell, linux-next, linux-kernel, Tejun Heo
On Wed, 25 Aug 2010, Christoph Lameter wrote:
> > > + * Special hack for UP mode. allocpercpu() falls back to kmalloc
> > > + * operations. So we cannot use that before the slab allocator is up
> > > + * Simply get the smallest possible compound page. The page will be
> > > + * released via kfree() when the cpu caches are resized later.
> > > + */
> > > + if (slab_state < UP)
> > > + s->cpu_slab = (__percpu void *)__get_free_page(GFP_NOWAIT, 1);
> >
> > __get_free_pages() takes an order argument.
>
> Right. Patch not refreshed after the last tinzy winzy change. Seems that I
> got a bit rusty.
>
> Subject: Slub: UP bandaid
>
> Since the percpu allocator does not provide early allocation in UP
> mode (only in SMP configurations) use __get_free_page() to improvise
> a compound page allocation that can be later freed via kfree().
>
> Compound pages will be released when the cpu caches are resized.
>
> Signed-off-by: Christoph Lameter <cl@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
I'm really hoping that we can remove this hack soon when the percpu
allocator can handle these allocations on UP without any specialized slab
behavior.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linux-next: build failure after merge of the final tree (slab tree related)
2010-08-26 0:01 ` David Rientjes
@ 2010-08-26 1:35 ` Christoph Lameter
2010-08-26 3:16 ` David Rientjes
0 siblings, 1 reply; 20+ messages in thread
From: Christoph Lameter @ 2010-08-26 1:35 UTC (permalink / raw)
To: David Rientjes
Cc: Pekka Enberg, Stephen Rothwell, linux-next, linux-kernel, Tejun Heo
On Wed, 25 Aug 2010, David Rientjes wrote:
> > + * Special hack for UP mode. allocpercpu() falls back to kmalloc
> > + * operations. So we cannot use that before the slab allocator is up
> > + * Simply get the smallest possible compound page. The page will be
> > + * released via kfree() when the cpu caches are resized later.
> > + */
> > + if (slab_state < UP)
> > + s->cpu_slab = (__percpu void *)__get_free_page(GFP_NOWAIT, 1);
>
> __get_free_pages() takes an order argument.
Right. Patch not refreshed after the last tinzy winzy change. Seems that I
got a bit rusty.
Subject: Slub: UP bandaid
Since the percpu allocator does not provide early allocation in UP
mode (only in SMP configurations) use __get_free_page() to improvise
a compound page allocation that can be later freed via kfree().
Compound pages will be released when the cpu caches are resized.
Signed-off-by: Christoph Lameter <cl@linux.com>
---
mm/slub.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
Index: linux-2.6/mm/slub.c
===================================================================
--- linux-2.6.orig/mm/slub.c 2010-08-25 09:00:59.000000000 -0500
+++ linux-2.6/mm/slub.c 2010-08-25 10:59:30.000000000 -0500
@@ -2091,8 +2091,24 @@ init_kmem_cache_node(struct kmem_cache_n
static inline int alloc_kmem_cache_cpus(struct kmem_cache *s)
{
+#ifdef CONFIG_SMP
+ /*
+ * Will use reserve that does not require slab operation during
+ * early boot.
+ */
BUILD_BUG_ON(PERCPU_DYNAMIC_EARLY_SIZE <
SLUB_PAGE_SHIFT * sizeof(struct kmem_cache_cpu));
+#else
+ /*
+ * Special hack for UP mode. allocpercpu() falls back to kmalloc
+ * operations. So we cannot use that before the slab allocator is up
+ * Simply get the smallest possible compound page. The page will be
+ * released via kfree() when the cpu caches are resized later.
+ */
+ if (slab_state < UP)
+ s->cpu_slab = (__percpu void *)__get_free_pages(GFP_NOWAIT, 1);
+ else
+#endif
s->cpu_slab = alloc_percpu(struct kmem_cache_cpu);
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linux-next: build failure after merge of the final tree (slab tree related)
2010-08-25 14:07 ` Christoph Lameter
@ 2010-08-26 0:01 ` David Rientjes
2010-08-26 1:35 ` Christoph Lameter
0 siblings, 1 reply; 20+ messages in thread
From: David Rientjes @ 2010-08-26 0:01 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Stephen Rothwell, linux-next, linux-kernel, Tejun Heo
On Wed, 25 Aug 2010, Christoph Lameter wrote:
> Since the percpu allocator does not provide early allocation in UP
> mode (only in SMP configurations) use __get_free_page() to improvise
> a compound page allocation that can be later freed via kfree().
>
> Compound pages will be released when the cpu caches are resized.
>
> Signed-off-by: Christoph Lameter <cl@linux.com>
>
> ---
> mm/slub.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> Index: linux-2.6/mm/slub.c
> ===================================================================
> --- linux-2.6.orig/mm/slub.c 2010-08-24 20:07:12.766010774 -0500
> +++ linux-2.6/mm/slub.c 2010-08-24 20:15:46.304130417 -0500
> @@ -2064,8 +2064,24 @@
>
> static inline int alloc_kmem_cache_cpus(struct kmem_cache *s)
> {
> +#ifdef CONFIG_SMP
> + /*
> + * Will use reserve that does not require slab operation during
> + * early boot.
> + */
> BUILD_BUG_ON(PERCPU_DYNAMIC_EARLY_SIZE <
> SLUB_PAGE_SHIFT * sizeof(struct kmem_cache_cpu));
> +#else
> + /*
> + * Special hack for UP mode. allocpercpu() falls back to kmalloc
> + * operations. So we cannot use that before the slab allocator is up
> + * Simply get the smallest possible compound page. The page will be
> + * released via kfree() when the cpu caches are resized later.
> + */
> + if (slab_state < UP)
> + s->cpu_slab = (__percpu void *)__get_free_page(GFP_NOWAIT, 1);
__get_free_pages() takes an order argument.
> + else
> +#endif
>
> s->cpu_slab = alloc_percpu(struct kmem_cache_cpu);
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linux-next: build failure after merge of the final tree (slab tree related)
2010-08-25 20:12 ` Christoph Lameter
@ 2010-08-25 21:37 ` Christoph Lameter
0 siblings, 0 replies; 20+ messages in thread
From: Christoph Lameter @ 2010-08-25 21:37 UTC (permalink / raw)
To: Tejun Heo; +Cc: Pekka Enberg, Stephen Rothwell, linux-next, linux-kernel
Err... Sorry there was patch under testing in there (remove the boot
pageset from the page allocator and use early allocpercpu) which resulted
in the reserve area becoming a bit tight. Sorry.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linux-next: build failure after merge of the final tree (slab tree related)
2010-08-25 8:18 ` Tejun Heo
2010-08-25 8:57 ` Pekka Enberg
@ 2010-08-25 20:12 ` Christoph Lameter
2010-08-25 21:37 ` Christoph Lameter
1 sibling, 1 reply; 20+ messages in thread
From: Christoph Lameter @ 2010-08-25 20:12 UTC (permalink / raw)
To: Tejun Heo; +Cc: Pekka Enberg, Stephen Rothwell, linux-next, linux-kernel
On Wed, 25 Aug 2010, Tejun Heo wrote:
> Eh... nasty. Maybe we can create a alloc_percpu_early() function
> which doesn't allow freeing of allocate memory and just redirect to
> bootmem on UP?
The whole early alloc stuff does also does not go over too well with the
page allocator (never had trouble on KVM):
Decompressing Linux... Parsing ELF... done.
Booting the kernel.
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.36-rc2 (root@rd-rsync) (gcc version 4.4.4 (Debian
4.4.4-5) ) #1 SMP Wed Aug 25 13:26:59 CDT 2010
Command line: ro root=/dev/mapper/vgubuntu-root console=tty0
console=ttyS1,57600 idle=mwait earlyprintk=ttyS1,57600
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
BIOS-e820: 0000000000100000 - 00000000cf699000 (usable)
BIOS-e820: 00000000cf699000 - 00000000cf6af000 (reserved)
BIOS-e820: 00000000cf6af000 - 00000000cf6ce000 (ACPI data)
BIOS-e820: 00000000cf6ce000 - 00000000d0000000 (reserved)
BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
BIOS-e820: 00000000fe000000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 00000001b0000000 (usable)
bootconsole [earlyser0] enabled
NX (Execute Disable) protection: active
DMI 2.6 present.
No AGP bridge found
last_pfn = 0x1b0000 max_arch_pfn = 0x400000000
last_pfn = 0xcf699 max_arch_pfn = 0x400000000
found SMP MP-table at [ffff8800000fe710] fe710
init_memory_mapping: 0000000000000000-00000000cf699000
init_memory_mapping: 0000000100000000-00000001b0000000
RAMDISK: 37b98000 - 37ff0000
ACPI: RSDP 00000000000f1630 00024 (v02 DELL )
ACPI: XSDT 00000000000f1734 0009C (v01 DELL PE_SC3 00000001 DELL
00000001)
ACPI: FACP 00000000cf6c3f9c 000F4 (v03 DELL PE_SC3 00000001 DELL
00000001)
ACPI: DSDT 00000000cf6af000 0320F (v01 DELL PE_SC3 00000001 INTL
20050624)
ACPI: FACS 00000000cf6c6000 00040
ACPI: APIC 00000000cf6c3478 0015E (v01 DELL PE_SC3 00000001 DELL
00000001)
ACPI: SPCR 00000000cf6c35d8 00050 (v01 DELL PE_SC3 00000001 DELL
00000001)
ACPI: HPET 00000000cf6c362c 00038 (v01 DELL PE_SC3 00000001 DELL
00000001)
ACPI: DM__ 00000000cf6c3668 001A8 (v01 DELL PE_SC3 00000001 DELL
00000001)
ACPI: MCFG 00000000cf6c38c4 0003C (v01 DELL PE_SC3 00000001 DELL
00000001)
ACPI: WD__ 00000000cf6c3904 00134 (v01 DELL PE_SC3 00000001 DELL
00000001)
ACPI: SLIC 00000000cf6c3a3c 00176 (v01 DELL PE_SC3 00000001 DELL
00000001)
ACPI: ERST 00000000cf6b2390 00270 (v01 DELL PE_SC3 00000001 DELL
00000001)
ACPI: HEST 00000000cf6b2600 0027C (v01 DELL PE_SC3 00000001 DELL
00000001)
ACPI: BERT 00000000cf6b2210 00030 (v01 DELL PE_SC3 00000001 DELL
00000001)
ACPI: EINJ 00000000cf6b2240 00150 (v01 DELL PE_SC3 00000001 DELL
00000001)
ACPI: SRAT 00000000cf6c3bc0 00370 (v01 DELL PE_SC3 00000001 DELL
00000001)
ACPI: TCPA 00000000cf6c3f34 00064 (v02 DELL PE_SC3 00000001 DELL
00000001)
ACPI: SSDT 00000000cf6c7000 04BE4 (v01 INTEL PPM RCM 80000001 INTL
20061109)
SRAT: PXM 1 -> APIC 0x10 -> Node 0
SRAT: PXM 2 -> APIC 0x00 -> Node 1
SRAT: PXM 1 -> APIC 0x12 -> Node 0
SRAT: PXM 2 -> APIC 0x02 -> Node 1
SRAT: PXM 1 -> APIC 0x14 -> Node 0
SRAT: PXM 2 -> APIC 0x04 -> Node 1
SRAT: PXM 1 -> APIC 0x16 -> Node 0
SRAT: PXM 2 -> APIC 0x06 -> Node 1
SRAT: PXM 1 -> APIC 0x11 -> Node 0
SRAT: PXM 2 -> APIC 0x01 -> Node 1
SRAT: PXM 1 -> APIC 0x13 -> Node 0
SRAT: PXM 2 -> APIC 0x03 -> Node 1
SRAT: PXM 1 -> APIC 0x15 -> Node 0
SRAT: PXM 2 -> APIC 0x05 -> Node 1
SRAT: PXM 1 -> APIC 0x17 -> Node 0
SRAT: PXM 2 -> APIC 0x07 -> Node 1
SRAT: Node 1 PXM 2 0-c0000000
SRAT: Node 0 PXM 1 c0000000-d0000000
SRAT: Node 0 PXM 1 100000000-1b0000000
SRAT: Node 0 [c0000000,d0000000) + [100000000,1b0000000) ->
[c0000000,1b0000000)
Initmem setup node 0 00000000c0000000-00000001b0000000
NODE_DATA [0000000100000000 - 0000000100004fff]
Initmem setup node 1 0000000000000000-00000000c0000000
NODE_DATA [00000000016ee780 - 00000000016f377f]
Zone PFN ranges:
DMA 0x00000001 -> 0x00001000
DMA32 0x00001000 -> 0x00100000
Normal 0x00100000 -> 0x001b0000
Movable zone start PFN for each node
early_node_map[4] active PFN ranges
1: 0x00000001 -> 0x000000a0
1: 0x00000100 -> 0x000c0000
0: 0x000c0000 -> 0x000cf699
0: 0x00100000 -> 0x001b0000
------------[ cut here ]------------
WARNING: at mm/percpu.c:285 pcpu_mem_alloc+0x31/0x78()
Hardware name: PowerEdge R610
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.36-rc2 #1
Call Trace:
[<ffffffff810305fa>] warn_slowpath_common+0x80/0x98
[<ffffffff81030627>] warn_slowpath_null+0x15/0x17
[<ffffffff810a226c>] pcpu_mem_alloc+0x31/0x78
[<ffffffff810a2fe1>] pcpu_alloc+0x243/0x8d9
[<ffffffff81030c85>] ? release_console_sem+0x185/0x1b6
[<ffffffff810a3692>] __alloc_percpu+0xb/0xd
[<ffffffff81601d6f>] free_area_init_node+0x235/0x350
[<ffffffff815e9c65>] free_area_init_nodes+0x4c1/0x50b
[<ffffffff815eb13c>] ? sparse_init+0x292/0x2cf
[<ffffffff815e2d50>] paging_init+0x53/0x5a
[<ffffffff815d642f>] setup_arch+0x82c/0x8b8
[<ffffffff813ad816>] ? printk+0x3c/0x3e
[<ffffffff8104f548>] ? clockevents_register_notifier+0x3e/0x4a
[<ffffffff815d29df>] start_kernel+0x88/0x351
[<ffffffff815d22a3>] x86_64_start_reservations+0xb3/0xb7
[<ffffffff815d238b>] x86_64_start_kernel+0xe4/0xeb
---[ end trace 4eaa2a86a8e2da22 ]---
PERCPU: allocation failed, size=96 align=8, failed to allocate new chunk
Pid: 0, comm: swapper Tainted: G W 2.6.36-rc2 #1
Call Trace:
[<ffffffff810a35ca>] pcpu_alloc+0x82c/0x8d9
[<ffffffff81030c85>] ? release_console_sem+0x185/0x1b6
[<ffffffff810a3692>] __alloc_percpu+0xb/0xd
[<ffffffff81601d6f>] free_area_init_node+0x235/0x350
[<ffffffff815e9c65>] free_area_init_nodes+0x4c1/0x50b
[<ffffffff815eb13c>] ? sparse_init+0x292/0x2cf
[<ffffffff815e2d50>] paging_init+0x53/0x5a
[<ffffffff815d642f>] setup_arch+0x82c/0x8b8
[<ffffffff813ad816>] ? printk+0x3c/0x3e
[<ffffffff8104f548>] ? clockevents_register_notifier+0x3e/0x4a
[<ffffffff815d29df>] start_kernel+0x88/0x351
[<ffffffff815d22a3>] x86_64_start_reservations+0xb3/0xb7
[<ffffffff815d238b>] x86_64_start_kernel+0xe4/0xeb
---[ end trace 4eaa2a86a8e2da22 ]---
PERCPU: allocation failed, size=96 align=8, failed to allocate new chunk
Pid: 0, comm: swapper Tainted: G W 2.6.36-rc2 #1
Call Trace:
[<ffffffff810a35ca>] pcpu_alloc+0x82c/0x8d9
[<ffffffff81030c85>] ? release_console_sem+0x185/0x1b6
[<ffffffff810a3692>] __alloc_percpu+0xb/0xd
[<ffffffff81601d6f>] free_area_init_node+0x235/0x350
[<ffffffff815e9c65>] free_area_init_nodes+0x4c1/0x50b
[<ffffffff815eb13c>] ? sparse_init+0x292/0x2cf
[<ffffffff815e2d50>] paging_init+0x53/0x5a
[<ffffffff815d642f>] setup_arch+0x82c/0x8b8
[<ffffffff813ad816>] ? printk+0x3c/0x3e
[<ffffffff8104f548>] ? clockevents_register_notifier+0x3e/0x4a
[<ffffffff815d29df>] start_kernel+0x88/0x351
[<ffffffff815d22a3>] x86_64_start_reservations+0xb3/0xb7
[<ffffffff815d238b>] x86_64_start_kernel+0xe4/0xeb
PERCPU: allocation failed, size=96 align=8, failed to allocate new chunk
Pid: 0, comm: swapper Tainted: G W 2.6.36-rc2 #1
Call Trace:
[<ffffffff810a35ca>] pcpu_alloc+0x82c/0x8d9
[<ffffffff81030c85>] ? release_console_sem+0x185/0x1b6
[<ffffffff810a3692>] __alloc_percpu+0xb/0xd
[<ffffffff81601d6f>] free_area_init_node+0x235/0x350
[<ffffffff815e9c65>] free_area_init_nodes+0x4c1/0x50b
[<ffffffff815eb13c>] ? sparse_init+0x292/0x2cf
[<ffffffff815e2d50>] paging_init+0x53/0x5a
[<ffffffff815d642f>] setup_arch+0x82c/0x8b8
[<ffffffff813ad816>] ? printk+0x3c/0x3e
[<ffffffff8104f548>] ? clockevents_register_notifier+0x3e/0x4a
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linux-next: build failure after merge of the final tree (slab tree related)
2010-08-25 4:46 ` Pekka Enberg
@ 2010-08-25 14:07 ` Christoph Lameter
2010-08-26 0:01 ` David Rientjes
0 siblings, 1 reply; 20+ messages in thread
From: Christoph Lameter @ 2010-08-25 14:07 UTC (permalink / raw)
To: Pekka Enberg; +Cc: Stephen Rothwell, linux-next, linux-kernel, Tejun Heo
On Wed, 25 Aug 2010, Pekka Enberg wrote:
> I dropped slub cleanups from -next until we've resolved the UP boot time crash
> problem.
>
It works here with this patch. I'd rather see a general solution so that
we can use allocpercpu for bootstrapping any allocator without such
special bandaids.
Subject: Slub: UP bandaid
Since the percpu allocator does not provide early allocation in UP
mode (only in SMP configurations) use __get_free_page() to improvise
a compound page allocation that can be later freed via kfree().
Compound pages will be released when the cpu caches are resized.
Signed-off-by: Christoph Lameter <cl@linux.com>
---
mm/slub.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6/mm/slub.c
===================================================================
--- linux-2.6.orig/mm/slub.c 2010-08-24 20:07:12.766010774 -0500
+++ linux-2.6/mm/slub.c 2010-08-24 20:15:46.304130417 -0500
@@ -2064,8 +2064,24 @@
static inline int alloc_kmem_cache_cpus(struct kmem_cache *s)
{
+#ifdef CONFIG_SMP
+ /*
+ * Will use reserve that does not require slab operation during
+ * early boot.
+ */
BUILD_BUG_ON(PERCPU_DYNAMIC_EARLY_SIZE <
SLUB_PAGE_SHIFT * sizeof(struct kmem_cache_cpu));
+#else
+ /*
+ * Special hack for UP mode. allocpercpu() falls back to kmalloc
+ * operations. So we cannot use that before the slab allocator is up
+ * Simply get the smallest possible compound page. The page will be
+ * released via kfree() when the cpu caches are resized later.
+ */
+ if (slab_state < UP)
+ s->cpu_slab = (__percpu void *)__get_free_page(GFP_NOWAIT, 1);
+ else
+#endif
s->cpu_slab = alloc_percpu(struct kmem_cache_cpu);
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linux-next: build failure after merge of the final tree (slab tree related)
2010-08-25 8:57 ` Pekka Enberg
@ 2010-08-25 13:50 ` Christoph Lameter
2010-08-26 8:35 ` Tejun Heo
0 siblings, 1 reply; 20+ messages in thread
From: Christoph Lameter @ 2010-08-25 13:50 UTC (permalink / raw)
To: Pekka Enberg; +Cc: Tejun Heo, Stephen Rothwell, linux-next, linux-kernel
On Wed, 25 Aug 2010, Pekka Enberg wrote:
> On 8/25/10 11:18 AM, Tejun Heo wrote:
> > Hello,
> >
> > On 08/24/2010 08:53 PM, Christoph Lameter wrote:
> > > > [ 0.000000] Kernel panic - not syncing: Cannot create slab kmem_cache
> > > > size=232 realsize=256 order=0 offset=0 flags=42000
> > >
> > > alloc per cpu result in kmalloc which fails.
> > >
> > > Tejon: Is there some way we could get a reserved per cpu area under UP
> > > instead of fallback to slab allocations during bootup?
> >
> > Eh... nasty. Maybe we can create a alloc_percpu_early() function
> > which doesn't allow freeing of allocate memory and just redirect to
> > bootmem on UP?
>
> Yeah, I was thinking about that too.
Another solution is to allocate an order 1 (compound) page for each early
cache. Then resize the kmalloc array after everything is up. kfree() will
then redirect to the page allocator.
But this is a slab allocator specific solution.
We now have the situation that alloc_percpu can only be used on early boot
on SMP machines. A general solution would be better I think.
If the early alloc_percpu stuff would work consistently then it could also
be used to avoid the boot_pageset in the page allocator f.e.
Can we just get rid of the special UP case and just run the percpu
subsystem even for UP?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linux-next: build failure after merge of the final tree (slab tree related)
2010-08-25 8:18 ` Tejun Heo
@ 2010-08-25 8:57 ` Pekka Enberg
2010-08-25 13:50 ` Christoph Lameter
2010-08-25 20:12 ` Christoph Lameter
1 sibling, 1 reply; 20+ messages in thread
From: Pekka Enberg @ 2010-08-25 8:57 UTC (permalink / raw)
To: Tejun Heo; +Cc: Christoph Lameter, Stephen Rothwell, linux-next, linux-kernel
On 8/25/10 11:18 AM, Tejun Heo wrote:
> Hello,
>
> On 08/24/2010 08:53 PM, Christoph Lameter wrote:
>>> [ 0.000000] Kernel panic - not syncing: Cannot create slab kmem_cache
>>> size=232 realsize=256 order=0 offset=0 flags=42000
>>
>> alloc per cpu result in kmalloc which fails.
>>
>> Tejon: Is there some way we could get a reserved per cpu area under UP
>> instead of fallback to slab allocations during bootup?
>
> Eh... nasty. Maybe we can create a alloc_percpu_early() function
> which doesn't allow freeing of allocate memory and just redirect to
> bootmem on UP?
Yeah, I was thinking about that too.
Pekka
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linux-next: build failure after merge of the final tree (slab tree related)
2010-08-24 18:53 ` Christoph Lameter
@ 2010-08-25 8:18 ` Tejun Heo
2010-08-25 8:57 ` Pekka Enberg
2010-08-25 20:12 ` Christoph Lameter
0 siblings, 2 replies; 20+ messages in thread
From: Tejun Heo @ 2010-08-25 8:18 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Stephen Rothwell, linux-next, linux-kernel
Hello,
On 08/24/2010 08:53 PM, Christoph Lameter wrote:
>> [ 0.000000] Kernel panic - not syncing: Cannot create slab kmem_cache
>> size=232 realsize=256 order=0 offset=0 flags=42000
>
> alloc per cpu result in kmalloc which fails.
>
> Tejon: Is there some way we could get a reserved per cpu area under UP
> instead of fallback to slab allocations during bootup?
Eh... nasty. Maybe we can create a alloc_percpu_early() function
which doesn't allow freeing of allocate memory and just redirect to
bootmem on UP?
--
tejun
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linux-next: build failure after merge of the final tree (slab tree related)
2010-08-25 0:13 ` Stephen Rothwell
@ 2010-08-25 4:46 ` Pekka Enberg
2010-08-25 14:07 ` Christoph Lameter
0 siblings, 1 reply; 20+ messages in thread
From: Pekka Enberg @ 2010-08-25 4:46 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Christoph Lameter, linux-next, linux-kernel
On 25.8.2010 3.13, Stephen Rothwell wrote:
> Hi Pekka,
>
> On Tue, 24 Aug 2010 20:41:36 +0300 Pekka Enberg<penberg@cs.helsinki.fi> wrote:
>>
>> Thanks for the report. The problem should be fixed by this commit:
>>
>> http://git.kernel.org/?p=linux/kernel/git/penberg/slab-2.6.git;a=commitdiff;h=5792949c540c9fd719c3fc0d6edc97374222e792
>
> A small point: I did *not* review that patch. I *did* report the bug
> (and seemingly provided the commit message).
Oh, sorry about that.
> Thanks for the build fix.
I dropped slub cleanups from -next until we've resolved the UP boot time
crash problem.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linux-next: build failure after merge of the final tree (slab tree related)
2010-08-24 17:41 ` Pekka Enberg
2010-08-24 17:59 ` Christoph Lameter
@ 2010-08-25 0:13 ` Stephen Rothwell
2010-08-25 4:46 ` Pekka Enberg
1 sibling, 1 reply; 20+ messages in thread
From: Stephen Rothwell @ 2010-08-25 0:13 UTC (permalink / raw)
To: Pekka Enberg; +Cc: Christoph Lameter, linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 549 bytes --]
Hi Pekka,
On Tue, 24 Aug 2010 20:41:36 +0300 Pekka Enberg <penberg@cs.helsinki.fi> wrote:
>
> Thanks for the report. The problem should be fixed by this commit:
>
> http://git.kernel.org/?p=linux/kernel/git/penberg/slab-2.6.git;a=commitdiff;h=5792949c540c9fd719c3fc0d6edc97374222e792
A small point: I did *not* review that patch. I *did* report the bug
(and seemingly provided the commit message).
Thanks for the build fix.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linux-next: build failure after merge of the final tree (slab tree related)
2010-08-24 18:32 ` Pekka Enberg
@ 2010-08-24 18:53 ` Christoph Lameter
2010-08-25 8:18 ` Tejun Heo
0 siblings, 1 reply; 20+ messages in thread
From: Christoph Lameter @ 2010-08-24 18:53 UTC (permalink / raw)
To: Pekka Enberg; +Cc: Stephen Rothwell, linux-next, linux-kernel, Tejun Heo
On Tue, 24 Aug 2010, Pekka Enberg wrote:
> On 24.8.2010 20.59, Christoph Lameter wrote:
> > On Tue, 24 Aug 2010, Pekka Enberg wrote:
> >
> > > Thanks for the report. The problem should be fixed by this commit:
> >
> > Its not that easy. __alloc_percpu falls back to kzalloc() on UP and this
> > can result in unique bootstrap problems with UP since the bootstrap array
> > is no longer there. Does the UP kernel boot?
>
> No, I get this under kvm:
> [ 0.000000] Kernel panic - not syncing: Cannot create slab kmem_cache
> size=232 realsize=256 order=0 offset=0 flags=42000
alloc per cpu result in kmalloc which fails.
Tejon: Is there some way we could get a reserved per cpu area under UP
instead of fallback to slab allocations during bootup?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linux-next: build failure after merge of the final tree (slab tree related)
2010-08-24 17:59 ` Christoph Lameter
@ 2010-08-24 18:32 ` Pekka Enberg
2010-08-24 18:53 ` Christoph Lameter
0 siblings, 1 reply; 20+ messages in thread
From: Pekka Enberg @ 2010-08-24 18:32 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Stephen Rothwell, linux-next, linux-kernel, Tejun Heo
On 24.8.2010 20.59, Christoph Lameter wrote:
> On Tue, 24 Aug 2010, Pekka Enberg wrote:
>
>> Thanks for the report. The problem should be fixed by this commit:
>
> Its not that easy. __alloc_percpu falls back to kzalloc() on UP and this
> can result in unique bootstrap problems with UP since the bootstrap array
> is no longer there. Does the UP kernel boot?
No, I get this under kvm:
[ 0.000000] Linux version 2.6.36-rc2+ (penberg@tiger) (gcc version
4.4.1 (Ubuntu 4.4.1-4ubuntu9) ) #103 Tue Aug 24 21:27:28 EEST 2010
[ 0.000000] Command line: notsc nolapic nosmp noacpi pci=conf1
earlyprintk=ttyS0,keep
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
[ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000f0000 - 00000000000fffff (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 0000000004000000 (usable)
[ 0.000000] console [earlyser0] enabled
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] DMI not present or invalid.
[ 0.000000] No AGP bridge found
[ 0.000000] last_pfn = 0x4000 max_arch_pfn = 0x400000000
[ 0.000000] x86 PAT enabled: cpu 0, old 0x0, new 0x7010600070106
[ 0.000000] CPU MTRRs all blank - virtualized system.
[ 0.000000] Scanning 1 areas for low memory corruption
[ 0.000000] modified physical RAM map:
[ 0.000000] modified: 0000000000000000 - 0000000000010000 (reserved)
[ 0.000000] modified: 0000000000010000 - 000000000009fc00 (usable)
[ 0.000000] modified: 000000000009fc00 - 00000000000a0000 (reserved)
[ 0.000000] modified: 00000000000f0000 - 00000000000fffff (reserved)
[ 0.000000] modified: 0000000000100000 - 0000000004000000 (usable)
[ 0.000000] init_memory_mapping: 0000000000000000-0000000004000000
[ 0.000000] ACPI Error: A valid RSDP was not found
(20100702/tbxfroot-219)
[ 0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00
[ 0.000000] kvm-clock: cpu 0, msr 0:1945621, boot clock
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0x00000010 -> 0x00001000
[ 0.000000] DMA32 0x00001000 -> 0x00100000
[ 0.000000] Normal empty
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[2] active PFN ranges
[ 0.000000] 0: 0x00000010 -> 0x0000009f
[ 0.000000] 0: 0x00000100 -> 0x00004000
[ 0.000000] No local APIC present
[ 0.000000] APIC: disable apic facility
[ 0.000000] APIC: switched to apic NOOP
[ 0.000000] PM: Registered nosave memory: 000000000009f000 -
00000000000a0000
[ 0.000000] PM: Registered nosave memory: 00000000000a0000 -
00000000000f0000
[ 0.000000] PM: Registered nosave memory: 00000000000f0000 -
00000000000ff000
[ 0.000000] PM: Registered nosave memory: 00000000000ff000 -
0000000000100000
[ 0.000000] Allocating PCI resources starting at 4000000 (gap:
4000000:fc000000)
[ 0.000000] Booting paravirtualized kernel on KVM
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 16047
[ 0.000000] Kernel command line: notsc nolapic nosmp noacpi pci=conf1
earlyprintk=ttyS0,keep
[ 0.000000] notsc: Kernel compiled with CONFIG_X86_TSC, cannot
disable TSC completely.
[ 0.000000] PID hash table entries: 256 (order: -1, 2048 bytes)
[ 0.000000] Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
[ 0.000000] Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.000000] Checking aperture...
[ 0.000000] No AGP bridge found
[ 0.000000] Subtract (23 early reservations)
[ 0.000000] #0 [0001000000 - 0001b751a0] TEXT DATA BSS
[ 0.000000] #1 [000009f000 - 0000100000] BIOS reserved
[ 0.000000] #2 [0000010000 - 0000012000] TRAMPOLINE
[ 0.000000] #3 [0000012000 - 0000016000] ACPI WAKEUP
[ 0.000000] #4 [0001b751c0 - 0001b761c0] BOOTMEM
[ 0.000000] #5 [0001f761c0 - 0001f761d8] BOOTMEM
[ 0.000000] #6 [0002377000 - 0002378000] BOOTMEM
[ 0.000000] #7 [0002378000 - 0002379000] BOOTMEM
[ 0.000000] #8 [0002400000 - 0002600000] MEMMAP 0
[ 0.000000] #9 [0001b761c0 - 0001b762c0] BOOTMEM
[ 0.000000] #10 [0001b762c0 - 0001b766c0] BOOTMEM
[ 0.000000] #11 [0001b77000 - 0001b78000] BOOTMEM
[ 0.000000] #12 [0001b766c0 - 0001b767d8] BOOTMEM
[ 0.000000] #13 [0001b76800 - 0001b76868] BOOTMEM
[ 0.000000] #14 [0001b76880 - 0001b768e8] BOOTMEM
[ 0.000000] #15 [0001b76900 - 0001b76968] BOOTMEM
[ 0.000000] #16 [0001b76980 - 0001b769e8] BOOTMEM
[ 0.000000] #17 [0001b76a00 - 0001b76a20] BOOTMEM
[ 0.000000] #18 [0001b76a40 - 0001b76a7d] BOOTMEM
[ 0.000000] #19 [0001b76a80 - 0001b76abd] BOOTMEM
[ 0.000000] #20 [0001b78000 - 0001b78800] BOOTMEM
[ 0.000000] #21 [0001b78800 - 0001b88800] BOOTMEM
[ 0.000000] #22 [0001b88800 - 0001b90800] BOOTMEM
[ 0.000000] Memory: 51156k/65536k available (6550k kernel code, 452k
absent, 13928k reserved, 3761k data, 764k init)
[ 0.000000] Kernel panic - not syncing: Cannot create slab kmem_cache
size=232 realsize=256 order=0 offset=0 flags=42000
[ 0.000000]
[ 0.000000] Pid: 0, comm: swapper Not tainted 2.6.36-rc2+ #103
[ 0.000000] Call Trace:
[ 0.000000] [<ffffffff81659a35>] panic+0x91/0x19b
[ 0.000000] [<ffffffff81126e59>] kmem_cache_open+0x1e9/0x200
[ 0.000000] [<ffffffff81a3141a>] kmem_cache_init+0x57/0x300
[ 0.000000] [<ffffffff81a14a97>] start_kernel+0x1ca/0x396
[ 0.000000] [<ffffffff81a14325>] x86_64_start_reservations+0x12c/0x130
[ 0.000000] [<ffffffff81a14423>] x86_64_start_kernel+0xfa/0x109
> Why did this ever build on my UP configuration tests? Hmmm... I only
> tested x86_64 UP. This was 32 bit UP I guess.
I could reproduce the build problem with x86-64 and !CONFIG_SMP so it's
not related to 32-bit.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linux-next: build failure after merge of the final tree (slab tree related)
2010-08-24 17:41 ` Pekka Enberg
@ 2010-08-24 17:59 ` Christoph Lameter
2010-08-24 18:32 ` Pekka Enberg
2010-08-25 0:13 ` Stephen Rothwell
1 sibling, 1 reply; 20+ messages in thread
From: Christoph Lameter @ 2010-08-24 17:59 UTC (permalink / raw)
To: Pekka Enberg; +Cc: Stephen Rothwell, linux-next, linux-kernel, Tejun Heo
On Tue, 24 Aug 2010, Pekka Enberg wrote:
> Thanks for the report. The problem should be fixed by this commit:
Its not that easy. __alloc_percpu falls back to kzalloc() on UP and this
can result in unique bootstrap problems with UP since the bootstrap array
is no longer there. Does the UP kernel boot?
Why did this ever build on my UP configuration tests? Hmmm... I only
tested x86_64 UP. This was 32 bit UP I guess.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linux-next: build failure after merge of the final tree (slab tree related)
2010-08-24 2:07 Stephen Rothwell
@ 2010-08-24 17:41 ` Pekka Enberg
2010-08-24 17:59 ` Christoph Lameter
2010-08-25 0:13 ` Stephen Rothwell
0 siblings, 2 replies; 20+ messages in thread
From: Pekka Enberg @ 2010-08-24 17:41 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Christoph Lameter, linux-next, linux-kernel
On 24.8.2010 5.07, Stephen Rothwell wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (powerpc
> allnoconfig) failed like this:
>
> mm/slub.c: In function 'alloc_kmem_cache_cpus':
> mm/slub.c:2094: error: 'PERCPU_DYNAMIC_EARLY_SIZE' undeclared (first use in this function)
> mm/slub.c:2094: error: (Each undeclared identifier is reported only once
> mm/slub.c:2094: error: for each function it appears in.)
> mm/slub.c:2094: error: bit-field '<anonymous>' width not an integer constant
>
> Caused by commit e18d65f0500b95d8724b17d8ea9f1116cf390bbe ("slub: Remove
> static kmem_cache_cpu array for boot"). PERCPU_DYNAMIC_EARLY_SIZE is only
> defined for SMP (and only in linux/percpu.h which is not explicitly
> included). This build does not have CONFIG_SMP set.
>
> I have used the version of the slab tree from next-20100823 for today.
Thanks for the report. The problem should be fixed by this commit:
http://git.kernel.org/?p=linux/kernel/git/penberg/slab-2.6.git;a=commitdiff;h=5792949c540c9fd719c3fc0d6edc97374222e792
^ permalink raw reply [flat|nested] 20+ messages in thread
* linux-next: build failure after merge of the final tree (slab tree related)
@ 2010-08-24 2:07 Stephen Rothwell
2010-08-24 17:41 ` Pekka Enberg
0 siblings, 1 reply; 20+ messages in thread
From: Stephen Rothwell @ 2010-08-24 2:07 UTC (permalink / raw)
To: Pekka Enberg, Christoph Lameter; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 916 bytes --]
Hi all,
After merging the final tree, today's linux-next build (powerpc
allnoconfig) failed like this:
mm/slub.c: In function 'alloc_kmem_cache_cpus':
mm/slub.c:2094: error: 'PERCPU_DYNAMIC_EARLY_SIZE' undeclared (first use in this function)
mm/slub.c:2094: error: (Each undeclared identifier is reported only once
mm/slub.c:2094: error: for each function it appears in.)
mm/slub.c:2094: error: bit-field '<anonymous>' width not an integer constant
Caused by commit e18d65f0500b95d8724b17d8ea9f1116cf390bbe ("slub: Remove
static kmem_cache_cpu array for boot"). PERCPU_DYNAMIC_EARLY_SIZE is only
defined for SMP (and only in linux/percpu.h which is not explicitly
included). This build does not have CONFIG_SMP set.
I have used the version of the slab tree from next-20100823 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2013-08-14 7:53 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-08-14 7:53 linux-next: build failure after merge of the final tree (slab tree related) Stephen Rothwell
-- strict thread matches above, loose matches on Subject: below --
2010-08-24 2:07 Stephen Rothwell
2010-08-24 17:41 ` Pekka Enberg
2010-08-24 17:59 ` Christoph Lameter
2010-08-24 18:32 ` Pekka Enberg
2010-08-24 18:53 ` Christoph Lameter
2010-08-25 8:18 ` Tejun Heo
2010-08-25 8:57 ` Pekka Enberg
2010-08-25 13:50 ` Christoph Lameter
2010-08-26 8:35 ` Tejun Heo
2010-08-25 20:12 ` Christoph Lameter
2010-08-25 21:37 ` Christoph Lameter
2010-08-25 0:13 ` Stephen Rothwell
2010-08-25 4:46 ` Pekka Enberg
2010-08-25 14:07 ` Christoph Lameter
2010-08-26 0:01 ` David Rientjes
2010-08-26 1:35 ` Christoph Lameter
2010-08-26 3:16 ` David Rientjes
2010-08-26 14:41 ` Christoph Lameter
2010-08-26 18:16 ` Pekka Enberg
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).