Alan Cox wrote:
> > +#if defined(CONFIG_X86) && !defined(CONFIG_M386)
> > +#define __ALIGN .align L1_CACHE_BYTES,0x90
> > +#if L1_CACHE_BYTES == 32
> > +#define __ALIGN_STR ".align 32,0x90"
> > +#else
> > +#define __ALIGN_STR ".align 16,0x90"
> > +#endif
> > +#else
>
> Please dont do this without doing a complete set of benchmarks on a variety
> of machines. On the K7 at least the cache footprint seems to outweigh the
> alignment values in general.
I agree with your warning about cache footprint but what you are saying
is to NOT fix the mechanism rather than TO fix the policy.
entry.S and head.S have 12 uses of ALIGN, several of which
would best be removed. It doesn't seem to be used anywhere else.
So we aren't talking about a whole lot of cache footprint here.
A much more egregious (and large) misuse of alignment
is in the whole of the kernel. Don't ya just love that gcc.
This is my compile line using gcc 2.95.1:
gcc -D__KERNEL__ -I/home/chris/linux/include -D__SMP__
-Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
-fno-strict-aliasing -pipe -fno-strength-reduce
-mpreferred-stack-boundary=2 -DCPU=686
-march=i686 -S arch/i386/kernel/ioport.c
-o arch/i386/kernel/ioport.s
And this is what you get for ioport.s
.file "ioport.c"
.version "01.01"
gcc2_compiled.:
.section .rodata
.LC0:
.string "eip: %p\n"
.align 32
.LC1:
.string "/home/chris/linux/include/asm/spinlock.h"
.LC2:
.string "kernel BUG at %s:%d!\n"
.LC3:
.string "wq bug, forcing oops.\n"
.align 32
.LC4:
.string "bad magic %lx (should be %lx, creator %lx), "
.align 32
.LC5:
.string "bad magic %lx (should be %lx), "
.align 32
I'm not exactly sure why "bad magic ..." desperately needs to be aligned.
Chris Sears
cbsears@ix.netcom.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:19 EST