Re: [tip:x86/apic] x86/apic: Limit irq affinity

[Dimitri Sivanich <sivanich@sgi.com>]

On Tue, Nov 10, 2009 at 05:40:25AM +0100, Ingo Molnar wrote:
> 
> * Dimitri Sivanich <sivanich@sgi.com> wrote:
> 
> > On Sun, Nov 08, 2009 at 03:53:55PM +0100, Ingo Molnar wrote:
> > > 
> > > * tip-bot for Dimitri Sivanich <sivanich@sgi.com> wrote:
> > > 
> > > > Commit-ID:  683c91f85d7a3e1092d7fa3ec5687af8cd379f02
> > > > Gitweb:     http://git.kernel.org/tip/683c91f85d7a3e1092d7fa3ec5687af8cd379f02
> > > > Author:     Dimitri Sivanich <sivanich@sgi.com>
> > > > AuthorDate: Tue, 3 Nov 2009 12:40:37 -0600
> > > > Committer:  Ingo Molnar <mingo@elte.hu>
> > > > CommitDate: Sun, 8 Nov 2009 13:30:40 +0100
> > > > 
> > > > x86/apic: Limit irq affinity
> > > > 
> > > > This patch allows for hard numa restrictions to irq affinity on
> > > > x86 systems.
> > > 
> > > -tip testing found a build failure:
> > > 
> > > arch/x86/kernel/apic/io_apic.c:1438: error: ???struct irq_desc??? has no member named ???node???
> > > arch/x86/kernel/apic/io_apic.c:3286: error: ???struct irq_desc??? has no member named ???node???
> > >
> > 
> > In the interest of doing some ifdef cleanup as well as fixing the 
> > build problem, can I suggest that we remove the 'ifdef CONFIG_SMP' 
> > from the irq_desc?
> 
> What's the (data and code) size effect on UP kernels?
> 

While I'm not fully certain what is best to report, here is output from
both 'size' and 'readelf'.

For the x86_32 case (the default configuration with SMP_CONFIG off):

Without the patch to remove '#ifdef CONFIG_SMP' from irq_desc:
$ size vmlinux
   text    data     bss     dec     hex filename
6853617  674868 1333604 8862089  873989 vmlinux

With the patch to remove '#ifdef CONFIG_SMP' from irq_desc:
$ size vmlinux
size vmlinux
   text    data     bss     dec     hex filename
6853621  674996 1333604 8862221  873a0d vmlinux

So it looks like we have 4 bytes more text and 128 bytes more data.

Looking at elf data, no MemSiz difference is apparent.

Without the patch:
$ readelf -l vmlinux
..
..
Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x001000 0xc1000000 0x01000000 0x651000 0x651000 R E 0x1000
  LOAD           0x652000 0xc1651000 0x01651000 0xdea1e 0x225000 RWE 0x1000
  NOTE           0x43bd4c 0xc143ad4c 0x0143ad4c 0x00024 0x00024     0x4

With the patch:
Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x001000 0xc1000000 0x01000000 0x651000 0x651000 R E 0x1000
  LOAD           0x652000 0xc1651000 0x01651000 0xdea1e 0x225000 RWE 0x1000
  NOTE           0x43bd44 0xc143ad44 0x0143ad44 0x00024 0x00024     0x4





For the x86_64 case:
Without patch on x86_64:
$ size vmlinux
   text    data     bss     dec     hex filename
6879227  731284  883216 8493727  819a9f vmlinux

With patch on x86_64:
$ size vmlinux
   text    data     bss     dec     hex filename
6879242  731524  883216 8493982  819b9e vmlinux

Looks like 15 bytes text and 240 bytes data.


Looking at elf data, there's a 256 byte difference in MemSiz data
(here I'm showing the output diff without/with the patch):

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000200000 0xffffffff81000000 0x0000000001000000
                 0x0000000000807000 0x0000000000807000  R E    200000
  LOAD           0x0000000000c00000 0xffffffff81a00000 0x0000000001a00000
-                0x0000000000088ff8 0x0000000000088ff8  RWE    200000
+                0x00000000000890f8 0x00000000000890f8  RWE    200000