Hi,
I get this from 2.6.12-rc3-mm3 on a UP AMD64 box (Asus L5D), 100% of the time:
]--snip--[
ACPI: bus type pci registered
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
kmem_cache_create: Early error in slab <NULL>
----------- [cut here ] --------- [please bite here ] ---------
Kernel BUG at "mm/slab.c":1219
invalid operand: 0000 [1]
CPU 0
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.12-rc3-mm3
RIP: 0010:[<ffffffff80179eeb>] <ffffffff80179eeb>{kmem_cache_create+139}
RSP: 0000:ffff810001ca1eb8 EFLAGS: 00010292
RAX: 0000000000000034 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000dd3 RDI: ffffffff804167e0
RBP: 0000000000000005 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000010 R11: 0000000000000008 R12: 0000000000042000
R13: 0000000000000000 R14: 0000ffffffff8010 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffffff8055a840(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000004000 CR3: 0000000000101000 CR4: 00000000000006e0
Process swapper (pid: 1, threadinfo ffff810001ca0000, task ffff810001c5a7a0)
Stack: fffffffffffffff8 0000000000000000 0000000000000000 0000000000000000
0000000000000010 0000000000000000 0000000000000005 0000000000000006
00000000ffffffff 0000ffffffff8010
Call Trace:<ffffffff8057a11d>{init_bio+93} <ffffffff8010c0f2>{init+178}
<ffffffff8010fc37>{child_rip+8} <ffffffff8010c040>{init+0}
<ffffffff8010fc2f>{child_rip+0}
Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
On Mon, May 09, 2005 at 10:39:37PM +0200, Rafael J. Wysocki wrote:
> Hi,
>
> I get this from 2.6.12-rc3-mm3 on a UP AMD64 box (Asus L5D), 100% of the time:
Probably a generic bug. Block layer is passing some slab flag slab doesn't like.
-Andi
>
> ]--snip--[
> ACPI: bus type pci registered
> PCI: Using configuration type 1
> mtrr: v2.0 (20020519)
> kmem_cache_create: Early error in slab <NULL>
> ----------- [cut here ] --------- [please bite here ] ---------
> Kernel BUG at "mm/slab.c":1219
> invalid operand: 0000 [1]
> CPU 0
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 2.6.12-rc3-mm3
> RIP: 0010:[<ffffffff80179eeb>] <ffffffff80179eeb>{kmem_cache_create+139}
> RSP: 0000:ffff810001ca1eb8 EFLAGS: 00010292
> RAX: 0000000000000034 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000dd3 RDI: ffffffff804167e0
> RBP: 0000000000000005 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000010 R11: 0000000000000008 R12: 0000000000042000
> R13: 0000000000000000 R14: 0000ffffffff8010 R15: 0000000000000000
> FS: 0000000000000000(0000) GS:ffffffff8055a840(0000) knlGS:0000000000000000
> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 0000000000004000 CR3: 0000000000101000 CR4: 00000000000006e0
> Process swapper (pid: 1, threadinfo ffff810001ca0000, task ffff810001c5a7a0)
> Stack: fffffffffffffff8 0000000000000000 0000000000000000 0000000000000000
> 0000000000000010 0000000000000000 0000000000000005 0000000000000006
> 00000000ffffffff 0000ffffffff8010
> Call Trace:<ffffffff8057a11d>{init_bio+93} <ffffffff8010c0f2>{init+178}
> <ffffffff8010fc37>{child_rip+8} <ffffffff8010c040>{init+0}
> <ffffffff8010fc2f>{child_rip+0}
>
>
> Greets,
> Rafael
>
>
> --
> - Would you tell me, please, which way I ought to go from here?
> - That depends a good deal on where you want to get to.
> -- Lewis Carroll "Alice's Adventures in Wonderland"
"Rafael J. Wysocki" <[email protected]> wrote:
>
> I get this from 2.6.12-rc3-mm3 on a UP AMD64 box (Asus L5D), 100% of the time:
>
> ]--snip--[
> ACPI: bus type pci registered
> PCI: Using configuration type 1
> mtrr: v2.0 (20020519)
> kmem_cache_create: Early error in slab <NULL>
> ----------- [cut here ] --------- [please bite here ] ---------
> Kernel BUG at "mm/slab.c":1219
> invalid operand: 0000 [1]
> CPU 0
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 2.6.12-rc3-mm3
> RIP: 0010:[<ffffffff80179eeb>] <ffffffff80179eeb>{kmem_cache_create+139}
> RSP: 0000:ffff810001ca1eb8 EFLAGS: 00010292
> RAX: 0000000000000034 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000dd3 RDI: ffffffff804167e0
> RBP: 0000000000000005 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000010 R11: 0000000000000008 R12: 0000000000042000
> R13: 0000000000000000 R14: 0000ffffffff8010 R15: 0000000000000000
> FS: 0000000000000000(0000) GS:ffffffff8055a840(0000) knlGS:0000000000000000
> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 0000000000004000 CR3: 0000000000101000 CR4: 00000000000006e0
> Process swapper (pid: 1, threadinfo ffff810001ca0000, task ffff810001c5a7a0)
> Stack: fffffffffffffff8 0000000000000000 0000000000000000 0000000000000000
> 0000000000000010 0000000000000000 0000000000000005 0000000000000006
> 00000000ffffffff 0000ffffffff8010
> Call Trace:<ffffffff8057a11d>{init_bio+93} <ffffffff8010c0f2>{init+178}
> <ffffffff8010fc37>{child_rip+8} <ffffffff8010c040>{init+0}
> <ffffffff8010fc2f>{child_rip+0}
>
Something kooky is happening.
Clearly init_bio() is not passing in a NULL `name' parameter. Maybe the
backtrace is screwed due to dopey gcc autoinlining and the bad caller is
really biovec_init_slabs(). Try removing the
__cacheline_aligned_mostly_readonly from the declaration of bvec_slabs[].
Please tell us what gcc and binutils versions you're using.
Rafael, under what scenario does it occur, do u have a
reproducible test case for this.
-lnxluv
--- "Rafael J. Wysocki" <[email protected]> wrote:
> Hi,
>
> I get this from 2.6.12-rc3-mm3 on a UP AMD64 box
> (Asus L5D), 100% of the time:
>
> ]--snip--[
> ACPI: bus type pci registered
> PCI: Using configuration type 1
> mtrr: v2.0 (20020519)
> kmem_cache_create: Early error in slab <NULL>
> ----------- [cut here ] --------- [please bite here
> ] ---------
> Kernel BUG at "mm/slab.c":1219
> invalid operand: 0000 [1]
> CPU 0
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 2.6.12-rc3-mm3
> RIP: 0010:[<ffffffff80179eeb>]
> <ffffffff80179eeb>{kmem_cache_create+139}
> RSP: 0000:ffff810001ca1eb8 EFLAGS: 00010292
> RAX: 0000000000000034 RBX: 0000000000000000 RCX:
> 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000dd3 RDI:
> ffffffff804167e0
> RBP: 0000000000000005 R08: 0000000000000000 R09:
> 0000000000000000
> R10: 0000000000000010 R11: 0000000000000008 R12:
> 0000000000042000
> R13: 0000000000000000 R14: 0000ffffffff8010 R15:
> 0000000000000000
> FS: 0000000000000000(0000)
> GS:ffffffff8055a840(0000) knlGS:0000000000000000
> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 0000000000004000 CR3: 0000000000101000 CR4:
> 00000000000006e0
> Process swapper (pid: 1, threadinfo
> ffff810001ca0000, task ffff810001c5a7a0)
> Stack: fffffffffffffff8 0000000000000000
> 0000000000000000 0000000000000000
> 0000000000000010 0000000000000000
> 0000000000000005 0000000000000006
> 00000000ffffffff 0000ffffffff8010
> Call Trace:<ffffffff8057a11d>{init_bio+93}
> <ffffffff8010c0f2>{init+178}
> <ffffffff8010fc37>{child_rip+8}
> <ffffffff8010c040>{init+0}
> <ffffffff8010fc2f>{child_rip+0}
>
>
> Greets,
> Rafael
__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail
On Mon, May 09 2005, Andi Kleen wrote:
> On Mon, May 09, 2005 at 10:39:37PM +0200, Rafael J. Wysocki wrote:
> > Hi,
> >
> > I get this from 2.6.12-rc3-mm3 on a UP AMD64 box (Asus L5D), 100% of the time:
>
> Probably a generic bug. Block layer is passing some slab flag slab
> doesn't like.
Some slab change, perhaps? There's nothing special about the init_bio()
slab call:
bio_slab = kmem_cache_create("bio", sizeof(struct bio), 0,
SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL, NULL);
Hmm, this looks strange. That bug happens if:
if ((!name) ||
in_interrupt() ||
(size < BYTES_PER_WORD) ||
(size > (1<<MAX_OBJ_ORDER)*PAGE_SIZE) ||
(dtor && !ctor)) {
printk(KERN_ERR "%s: Early error in slab %s\n",
__FUNCTION__, name);
BUG();
}
It must be in_interrupt() triggering, perhaps something change in the
boot sequence?
--
Jens Axboe
tis 2005-05-10 klockan 08:18 +0200 skrev Jens Axboe:
> On Mon, May 09 2005, Andi Kleen wrote:
> > On Mon, May 09, 2005 at 10:39:37PM +0200, Rafael J. Wysocki wrote:
> > > Hi,
> > >
> > > I get this from 2.6.12-rc3-mm3 on a UP AMD64 box (Asus L5D), 100% of the time:
> >
> > Probably a generic bug. Block layer is passing some slab flag slab
> > doesn't like.
>
> Some slab change, perhaps? There's nothing special about the init_bio()
> slab call:
>
> bio_slab = kmem_cache_create("bio", sizeof(struct bio), 0,
> SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL, NULL);
>
>
> Hmm, this looks strange. That bug happens if:
>
> if ((!name) ||
> in_interrupt() ||
> (size < BYTES_PER_WORD) ||
> (size > (1<<MAX_OBJ_ORDER)*PAGE_SIZE) ||
> (dtor && !ctor)) {
> printk(KERN_ERR "%s: Early error in slab %s\n",
> __FUNCTION__, name);
> BUG();
> }
>
> It must be in_interrupt() triggering, perhaps something change in the
> boot sequence?
>
The funny thing is that it seems to be the name being NULL, from the
original post:
kmem_cache_create: Early error in slab <NULL>
When looking at the code I really can't see how that can be. Rafael,
what setup is this compiled under?
On Tue, May 10 2005, Alexander Nyberg wrote:
> tis 2005-05-10 klockan 08:18 +0200 skrev Jens Axboe:
> > On Mon, May 09 2005, Andi Kleen wrote:
> > > On Mon, May 09, 2005 at 10:39:37PM +0200, Rafael J. Wysocki wrote:
> > > > Hi,
> > > >
> > > > I get this from 2.6.12-rc3-mm3 on a UP AMD64 box (Asus L5D), 100% of the time:
> > >
> > > Probably a generic bug. Block layer is passing some slab flag slab
> > > doesn't like.
> >
> > Some slab change, perhaps? There's nothing special about the init_bio()
> > slab call:
> >
> > bio_slab = kmem_cache_create("bio", sizeof(struct bio), 0,
> > SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL, NULL);
> >
> >
> > Hmm, this looks strange. That bug happens if:
> >
> > if ((!name) ||
> > in_interrupt() ||
> > (size < BYTES_PER_WORD) ||
> > (size > (1<<MAX_OBJ_ORDER)*PAGE_SIZE) ||
> > (dtor && !ctor)) {
> > printk(KERN_ERR "%s: Early error in slab %s\n",
> > __FUNCTION__, name);
> > BUG();
> > }
> >
> > It must be in_interrupt() triggering, perhaps something change in the
> > boot sequence?
> >
>
> The funny thing is that it seems to be the name being NULL, from the
> original post:
> kmem_cache_create: Early error in slab <NULL>
>
> When looking at the code I really can't see how that can be. Rafael,
> what setup is this compiled under?
Huh indeed, smells like bad code generation or hardware.
--
Jens Axboe
> Some slab change, perhaps? There's nothing special about the init_bio()
> slab call:
>
> bio_slab = kmem_cache_create("bio", sizeof(struct bio), 0,
> SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL, NULL);
>
>
> Hmm, this looks strange. That bug happens if:
>
> if ((!name) ||
> in_interrupt() ||
> (size < BYTES_PER_WORD) ||
> (size > (1<<MAX_OBJ_ORDER)*PAGE_SIZE) ||
> (dtor && !ctor)) {
> printk(KERN_ERR "%s: Early error in slab %s\n",
> __FUNCTION__, name);
> BUG();
> }
>
> It must be in_interrupt() triggering, perhaps something change in the
> boot sequence?
I would add a printk for all arguments on top of kmem_cache_create
and decompose the big if () into smaller if (...) BUG() so that you
can see which condition triggers exactly.
Then if you suspect compiler issues you can edit the Makefile and
recompile the kernel with -O1
Rafael, can you try that perhaps?
-Andi
Hi,
On Monday, 9 of May 2005 23:54, Andrew Morton wrote:
> "Rafael J. Wysocki" <[email protected]> wrote:
> >
> > I get this from 2.6.12-rc3-mm3 on a UP AMD64 box (Asus L5D), 100% of the time:
> >
> > ]--snip--[
> > ACPI: bus type pci registered
> > PCI: Using configuration type 1
> > mtrr: v2.0 (20020519)
> > kmem_cache_create: Early error in slab <NULL>
> > ----------- [cut here ] --------- [please bite here ] ---------
> > Kernel BUG at "mm/slab.c":1219
> > invalid operand: 0000 [1]
> > CPU 0
> > Modules linked in:
> > Pid: 1, comm: swapper Not tainted 2.6.12-rc3-mm3
> > RIP: 0010:[<ffffffff80179eeb>] <ffffffff80179eeb>{kmem_cache_create+139}
> > RSP: 0000:ffff810001ca1eb8 EFLAGS: 00010292
> > RAX: 0000000000000034 RBX: 0000000000000000 RCX: 0000000000000000
> > RDX: 0000000000000000 RSI: 0000000000000dd3 RDI: ffffffff804167e0
> > RBP: 0000000000000005 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000010 R11: 0000000000000008 R12: 0000000000042000
> > R13: 0000000000000000 R14: 0000ffffffff8010 R15: 0000000000000000
> > FS: 0000000000000000(0000) GS:ffffffff8055a840(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> > CR2: 0000000000004000 CR3: 0000000000101000 CR4: 00000000000006e0
> > Process swapper (pid: 1, threadinfo ffff810001ca0000, task ffff810001c5a7a0)
> > Stack: fffffffffffffff8 0000000000000000 0000000000000000 0000000000000000
> > 0000000000000010 0000000000000000 0000000000000005 0000000000000006
> > 00000000ffffffff 0000ffffffff8010
> > Call Trace:<ffffffff8057a11d>{init_bio+93} <ffffffff8010c0f2>{init+178}
> > <ffffffff8010fc37>{child_rip+8} <ffffffff8010c040>{init+0}
> > <ffffffff8010fc2f>{child_rip+0}
> >
>
> Something kooky is happening.
>
> Clearly init_bio() is not passing in a NULL `name' parameter. Maybe the
> backtrace is screwed due to dopey gcc autoinlining and the bad caller is
> really biovec_init_slabs(). Try removing the
> __cacheline_aligned_mostly_readonly from the declaration of bvec_slabs[].
>
> Please tell us what gcc and binutils versions you're using.
rafael@albercik:~> gcc -v
]--snip--[
gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)
rafael@albercik:~> ld -v
GNU ld version 2.15.94.0.2.2 20041220 (SuSE Linux)
rafael@albercik:~> as -v
GNU assembler version 2.15.94.0.2.2 (x86_64-suse-linux) using BFD version 2.15.94.0.2.2 20041220 (SuSE Linux)
It's the default setup for SUSE 9.3 64-bit.
Strangely enough, I've compiled 2.6.12-rc4 and 2.6.12-rc3-mm2 with the same
gcc/binutils and they work fine.
Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
Hi,
On Monday, 9 of May 2005 23:54, Andrew Morton wrote:
> "Rafael J. Wysocki" <[email protected]> wrote:
> >
> > I get this from 2.6.12-rc3-mm3 on a UP AMD64 box (Asus L5D), 100% of the time:
> >
> > ]--snip--[
> > ACPI: bus type pci registered
> > PCI: Using configuration type 1
> > mtrr: v2.0 (20020519)
> > kmem_cache_create: Early error in slab <NULL>
> > ----------- [cut here ] --------- [please bite here ] ---------
> > Kernel BUG at "mm/slab.c":1219
> > invalid operand: 0000 [1]
]--snip--[
>
> Something kooky is happening.
>
> Clearly init_bio() is not passing in a NULL `name' parameter. Maybe the
> backtrace is screwed due to dopey gcc autoinlining and the bad caller is
> really biovec_init_slabs(). Try removing the
> __cacheline_aligned_mostly_readonly from the declaration of bvec_slabs[].
Heh, it boots without the __cacheline_aligned_mostly_readonly (ie the BUG is
only triggered if the __cacheline_aligned_mostly_readonly is present in the
declaration of bvec_slabs[]). I've double-checked it. Interesting ... ;-)
Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
"Rafael J. Wysocki" <[email protected]> wrote:
>
> > Clearly init_bio() is not passing in a NULL `name' parameter. Maybe the
> > backtrace is screwed due to dopey gcc autoinlining and the bad caller is
> > really biovec_init_slabs(). Try removing the
> > __cacheline_aligned_mostly_readonly from the declaration of bvec_slabs[].
>
> Heh, it boots without the __cacheline_aligned_mostly_readonly (ie the BUG is
> only triggered if the __cacheline_aligned_mostly_readonly is present in the
> declaration of bvec_slabs[]). I've double-checked it. Interesting ... ;-)
oops.
+#ifdef CONFIG_X86
+#define __cacheline_aligned_mostly_readonly \
+ __attribute__((__aligned__(SMP_CACHE_BYTES), \
+ __section__(".data.mostly_readonly")))
+#else
+#define __cacheline_aligned_mostly_readonly __cacheline_aligned
+#endif
So on x86_64 we're putting __cacheline_aligned_mostly_readonly stuff into a
section which is not implemented anywhere. I'm rather surprised that the
kernel linked at all. But I'm more surprised that it mysteriously oopsed.
Oh well, I'll change that to CONFIG_X86 && !CONFIG_X86_64, thanks.
Or maybe Christoph wants to rustle up the x86_64 patch? We really should
patch all architectures if we're going to do this thing.
On Tue, May 10, 2005 at 11:22:24AM -0700, Andrew Morton wrote:
> "Rafael J. Wysocki" <[email protected]> wrote:
> >
> > > Clearly init_bio() is not passing in a NULL `name' parameter. Maybe the
> > > backtrace is screwed due to dopey gcc autoinlining and the bad caller is
> > > really biovec_init_slabs(). Try removing the
> > > __cacheline_aligned_mostly_readonly from the declaration of bvec_slabs[].
> >
> > Heh, it boots without the __cacheline_aligned_mostly_readonly (ie the BUG is
> > only triggered if the __cacheline_aligned_mostly_readonly is present in the
> > declaration of bvec_slabs[]). I've double-checked it. Interesting ... ;-)
>
> oops.
>
> +#ifdef CONFIG_X86
> +#define __cacheline_aligned_mostly_readonly \
> + __attribute__((__aligned__(SMP_CACHE_BYTES), \
> + __section__(".data.mostly_readonly")))
> +#else
> +#define __cacheline_aligned_mostly_readonly __cacheline_aligned
> +#endif
>
> So on x86_64 we're putting __cacheline_aligned_mostly_readonly stuff into a
> section which is not implemented anywhere. I'm rather surprised that the
> kernel linked at all. But I'm more surprised that it mysteriously oopsed.
>
> Oh well, I'll change that to CONFIG_X86 && !CONFIG_X86_64, thanks.
Better just add the section to x86-64. Should be easy by copying the
change from the i386 patch.
Ideally it would be asm-generic/vmlinux.lds and cover everybody...
-Andi
> Or maybe Christoph wants to rustle up the x86_64 patch? We really should
> patch all architectures if we're going to do this thing.
On Tue, 10 May 2005, Andi Kleen wrote:
> Better just add the section to x86-64. Should be easy by copying the
> change from the i386 patch.
Something like this?
Index: linux-2.6.11/arch/x86_64/kernel/vmlinux.lds.S
===================================================================
--- linux-2.6.11.orig/arch/x86_64/kernel/vmlinux.lds.S 2005-05-10 13:35:24.000000000 -0700
+++ linux-2.6.11/arch/x86_64/kernel/vmlinux.lds.S 2005-05-10 13:44:26.000000000 -0700
@@ -42,6 +42,13 @@ SECTIONS
CONSTRUCTORS
}
+ . = ALIGN(32);
+ .data.cacheline_aligned : { (.data.cacheline_aligned) }
+
+ /* Rarely changed data like cpu maps */
+ . = ALIGN(4096);
+ .data.mostly_readonly : { *(.data.mostly_readonly) }
+
_edata = .; /* End of data section */
__bss_start = .; /* BSS */
> Ideally it would be asm-generic/vmlinux.lds and cover everybody...
Hmm.. Add a definition for ALIGNED_DATA ?
On Tue, May 10, 2005 at 02:44:47PM -0700, Christoph Lameter wrote:
> On Tue, 10 May 2005, Andi Kleen wrote:
>
> > Better just add the section to x86-64. Should be easy by copying the
> > change from the i386 patch.
>
> Something like this?
>
> Index: linux-2.6.11/arch/x86_64/kernel/vmlinux.lds.S
> ===================================================================
> --- linux-2.6.11.orig/arch/x86_64/kernel/vmlinux.lds.S 2005-05-10 13:35:24.000000000 -0700
> +++ linux-2.6.11/arch/x86_64/kernel/vmlinux.lds.S 2005-05-10 13:44:26.000000000 -0700
> @@ -42,6 +42,13 @@ SECTIONS
> CONSTRUCTORS
> }
>
> + . = ALIGN(32);
This should be . = ALIGN(CONFIG_X86_L1_CACHE_BYTES)
It was wrong on i386 already btw, which needs the same.
> + .data.cacheline_aligned : { (.data.cacheline_aligned) }
> +
> + /* Rarely changed data like cpu maps */
> + . = ALIGN(4096);
Does it really need an 4096 byte alignment? That seems like
a waste of memory. Cache line alignment should be enough.
> + .data.mostly_readonly : { *(.data.mostly_readonly) }
> +
> _edata = .; /* End of data section */
>
> __bss_start = .; /* BSS */
>
> > Ideally it would be asm-generic/vmlinux.lds and cover everybody...
>
> Hmm.. Add a definition for ALIGNED_DATA ?
Thinking about it again there is no portable way to do the cacheline
alignment yet, so drop that suggestion please.
-Andi
>
On Tue, 10 May 2005, Andi Kleen wrote:
> > + . = ALIGN(32);
>
> This should be . = ALIGN(CONFIG_X86_L1_CACHE_BYTES)
>
> It was wrong on i386 already btw, which needs the same.
i386 always specifies the numbers and does not use symbolic constants.
We better leave that as it is.
> > + /* Rarely changed data like cpu maps */
> > + . = ALIGN(4096);
>
> Does it really need an 4096 byte alignment? That seems like
> a waste of memory. Cache line alignment should be enough.
Ok.
Index: linux-2.6.11/arch/i386/kernel/vmlinux.lds.S
===================================================================
--- linux-2.6.11.orig/arch/i386/kernel/vmlinux.lds.S 2005-05-10 13:35:25.000000000 -0700
+++ linux-2.6.11/arch/i386/kernel/vmlinux.lds.S 2005-05-10 13:59:18.000000000 -0700
@@ -58,7 +58,7 @@ SECTIONS
}
/* rarely changed data like cpu maps */
- . = ALIGN(4096);
+ . = ALIGN(32);
.data.mostly_readonly : AT(ADDR(.data.mostly_readonly) - LOAD_OFFSET) {
*(.data.mostly_readonly)
}
Index: linux-2.6.11/arch/x86_64/kernel/vmlinux.lds.S
===================================================================
--- linux-2.6.11.orig/arch/x86_64/kernel/vmlinux.lds.S 2005-05-10 13:35:24.000000000 -0700
+++ linux-2.6.11/arch/x86_64/kernel/vmlinux.lds.S 2005-05-10 14:02:06.000000000 -0700
@@ -42,6 +42,13 @@ SECTIONS
CONSTRUCTORS
}
+ . = ALIGN(CONFIG_X86_L1_CACHE_BYTES);
+ .data.cacheline_aligned : { (.data.cacheline_aligned) }
+
+ /* Rarely changed data like cpu maps */
+ . = ALIGN(CONFIG_X86_L1_CACHE_BYTES);
+ .data.mostly_readonly : { *(.data.mostly_readonly) }
+
_edata = .; /* End of data section */
__bss_start = .; /* BSS */
On Tue, May 10, 2005 at 03:01:13PM -0700, Christoph Lameter wrote:
> On Tue, 10 May 2005, Andi Kleen wrote:
>
> > > + . = ALIGN(32);
> >
> > This should be . = ALIGN(CONFIG_X86_L1_CACHE_BYTES)
> >
> > It was wrong on i386 already btw, which needs the same.
>
> i386 always specifies the numbers and does not use symbolic constants.
> We better leave that as it is.
That's broken then and needs to be fixed.
>
> > > + /* Rarely changed data like cpu maps */
> > > + . = ALIGN(4096);
> >
> > Does it really need an 4096 byte alignment? That seems like
> > a waste of memory. Cache line alignment should be enough.
>
> Ok.
Looks good.
-Andi
>
> Index: linux-2.6.11/arch/i386/kernel/vmlinux.lds.S
> ===================================================================
> --- linux-2.6.11.orig/arch/i386/kernel/vmlinux.lds.S 2005-05-10 13:35:25.000000000 -0700
> +++ linux-2.6.11/arch/i386/kernel/vmlinux.lds.S 2005-05-10 13:59:18.000000000 -0700
> @@ -58,7 +58,7 @@ SECTIONS
> }
>
> /* rarely changed data like cpu maps */
> - . = ALIGN(4096);
> + . = ALIGN(32);
> .data.mostly_readonly : AT(ADDR(.data.mostly_readonly) - LOAD_OFFSET) {
> *(.data.mostly_readonly)
> }
> Index: linux-2.6.11/arch/x86_64/kernel/vmlinux.lds.S
> ===================================================================
> --- linux-2.6.11.orig/arch/x86_64/kernel/vmlinux.lds.S 2005-05-10 13:35:24.000000000 -0700
> +++ linux-2.6.11/arch/x86_64/kernel/vmlinux.lds.S 2005-05-10 14:02:06.000000000 -0700
> @@ -42,6 +42,13 @@ SECTIONS
> CONSTRUCTORS
> }
>
> + . = ALIGN(CONFIG_X86_L1_CACHE_BYTES);
> + .data.cacheline_aligned : { (.data.cacheline_aligned) }
> +
> + /* Rarely changed data like cpu maps */
> + . = ALIGN(CONFIG_X86_L1_CACHE_BYTES);
> + .data.mostly_readonly : { *(.data.mostly_readonly) }
> +
> _edata = .; /* End of data section */
>
> __bss_start = .; /* BSS */