Re: [PATCH] __cacheline_aligned always in own section

[Andrew Morton]

Denis Vlasenko <vda@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> I compile my kernels for 486 but buils system aligns
> functions and labels to 16 bytes, with results like this:
> 
> 00000730 <islpci_eth_tx_timeout>:
>      730:       55                      push   %ebp
>      731:       89 e5                   mov    %esp,%ebp
>      733:       8b 45 08                mov    0x8(%ebp),%eax
>      736:       8b 40 64                mov    0x64(%eax),%eax
>      739:       05 14 03 00 00          add    $0x314,%eax
>      73e:       ff 40 14                incl   0x14(%eax)
>      741:       5d                      pop    %ebp
>      742:       c3                      ret
>      743:       90                      nop
>      744:       90                      nop
>      745:       90                      nop
>      746:       90                      nop
>      747:       90                      nop
>      748:       90                      nop
>      749:       90                      nop
>      74a:       90                      nop
>      74b:       90                      nop
>      74c:       90                      nop
>      74d:       90                      nop
>      74e:       90                      nop
>      74f:       90                      nop
> 
> Losing on average 15/2 bytes to alignment, my kernel lose
> # echo $((`cat System.map | grep '0 ' | wc -l`*15/2))
> 149632
> bytes only due to function alignment, not counting jump target
> alighment.
> 
> Is there any way to prevent this?

Yes, there are ways of turning off a lot of this alignment padding and it
makes a significant different in code size.  You need to dig around in the
gcc documentation for the several -*align* options.

IIRC, not all of the padding could be turned off (the gcc options were not
complete) but it's a couple of years since I investigated this.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/