[v1,1/2] x86: kconfig: remove X86_UP_IOAPIC

From: "Luis R. Rodriguez" <mcgrof@suse.com>

X86_UP_IOAPIC is a way so that 32-bit UP systems can enable
X86_IOAPIC. X86_UP_IOAPIC is only as a visible user option if
you are on a 32-bit system but have X86_UP_APIC enabled. X86_UP_APIC
will be enabled by force if you have PCI_MSI on 32-bit systems
now, X86_UP_APIC will now only be user selectable if you didn't
have PCI_MSI enabled and are also not on a X86_32_NON_STANDARD
system. Bryan's original patch (refactored commit log in commit
38a1dfda) [0] describes that Intel CE, Intel MID and Intel Quark
are all 32-bit uniprocessor systems with IO-APICs, the code change
however only *re-enabled* UP_IOAPIC as an *option* when PCI_MSI
was enabled, but given that:

1) enabling X86_IOAPIC is the real end goal here
2) enabling X86_IOAPIC only increases the kernel only by 12064 bytes (~12 KiB)
3) enabling X86_IOAPIC will in no way slow down your kernel

Let's make a compromise for 32-bit systems and always enable X86_IOAPIC
when X86_UP_IOAPIC is enabled as 32-bit systems are not in a state
of flux and the price for the size is small with no performance impact.

Using:

export ARCH=i386
make allnoconfig
--> Enabling PCI_MSI
make localyesconfig

With X86_IO_APIC:
mcgrof@ergon ~/linux-next (git::master)$ du -b arch/x86/boot/bzImage
734608  arch/x86/boot/bzImage

Without X86_IO_APIC:
mcgrof@ergon ~/linux-next (git::master)$ du -b arch/x86/boot/bzImage
722544  arch/x86/boot/bzImage

[0] https://lkml.org/lkml/2015/1/22/718

Cc: David Rientjes <rientjes@google.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: linux-pci@vger.kernel.org
Cc: x86@kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 arch/x86/Kconfig | 15 ++-------------
 1 file changed, 2 insertions(+), 13 deletions(-)

On 11/03/15 23:10, Luis R. Rodriguez wrote:

ACK the concept - the logic to compile up APIC support is circuitous to 
say the least.

Personally think we should just always compile up the APIC code if the 
arch declares support and let the bootstrap code interrogate CPUID. Who 
in 2015 is really running a system without an APIC/IO-APIC and 
tip-of-tree Linux and does that one user care about adding 12k to her 
kernel ? I suspect not and in any case can force the APIC off with a 
command line argument

> @@ -899,6 +899,7 @@ config X86_UP_APIC
>   	bool "Local APIC support on uniprocessors" if !PCI_MSI

Tried to apply this to torvalds-master to test :( Should it ? Which 
branch are you on here ?

Applying: x86: kconfig: remove X86_UP_IOAPIC
error: patch failed: arch/x86/Kconfig:899
error: arch/x86/Kconfig: patch does not apply
Patch failed at 0001 x86: kconfig: remove X86_UP_IOAPIC

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Thu, Mar 12, 2015 at 01:19:14AM +0000, Bryan O'Donoghue wrote:
> On 11/03/15 23:10, Luis R. Rodriguez wrote:
> 
> ACK the concept - the logic to compile up APIC support is circuitous
> to say the least.

It took me a while to grok this and indeed the goal was to make it
much simpler to read, but at the same time to see if we can reach
a compromise to simplify it for 32-bit.

> Personally think we should just always compile up the APIC code if
> the arch declares support and let the bootstrap code interrogate
> CPUID.

This would be the *next* level of compromise to make, I felt comfortable
in raising the size compromise question for 32-bit but its not clear
to me if this is a general question which we can address for all x86.
There is indeed no performance pentalty for both so the question comes
down to tex size increase, and its why I provided the numbers.

My preference was to leave the optimization question for all x86 as
a rather secondary question *iff* we can agree on something for 32-bit.

> Who in 2015 is really running a system without an
> APIC/IO-APIC and tip-of-tree Linux and does that one user care about
> adding 12k to her kernel ? I suspect not and in any case can force
> the APIC off with a command line argument

I also figured this was the case, but figured it was safer to pose
the question for 32-bit. If indeed folks who produce the hardware
can conclude the size increase is reasonable for all platforms
given no performance penalty then we can surely keep this even
simpler -- I think its safer to ask this question for 32-bit and
leave only the larger picture questoin as an evolutionairy question.

> >@@ -899,6 +899,7 @@ config X86_UP_APIC
> >  	bool "Local APIC support on uniprocessors" if !PCI_MSI
> 
> Tried to apply this to torvalds-master to test :( Should it ? Which
> branch are you on here ?
> 
> Applying: x86: kconfig: remove X86_UP_IOAPIC
> error: patch failed: arch/x86/Kconfig:899
> error: arch/x86/Kconfig: patch does not apply
> Patch failed at 0001 x86: kconfig: remove X86_UP_IOAPIC

linux-next tag next-20150311

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html