[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091110163118.GA13707@sgi.com>
Date: Tue, 10 Nov 2009 10:31:18 -0600
From: Dimitri Sivanich <sivanich@....com>
To: Ingo Molnar <mingo@...e.hu>
Cc: mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
yinghai@...nel.org, suresh.b.siddha@...el.com, tglx@...utronix.de
Subject: Re: [tip:x86/apic] x86/apic: Limit irq affinity
On Tue, Nov 10, 2009 at 05:40:25AM +0100, Ingo Molnar wrote:
>
> * Dimitri Sivanich <sivanich@....com> wrote:
>
> > On Sun, Nov 08, 2009 at 03:53:55PM +0100, Ingo Molnar wrote:
> > >
> > > * tip-bot for Dimitri Sivanich <sivanich@....com> wrote:
> > >
> > > > Commit-ID: 683c91f85d7a3e1092d7fa3ec5687af8cd379f02
> > > > Gitweb: http://git.kernel.org/tip/683c91f85d7a3e1092d7fa3ec5687af8cd379f02
> > > > Author: Dimitri Sivanich <sivanich@....com>
> > > > AuthorDate: Tue, 3 Nov 2009 12:40:37 -0600
> > > > Committer: Ingo Molnar <mingo@...e.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists