Re: [PATCH v1 1/2] x86: kconfig: remove X86_UP_IOAPIC

[Luis R. Rodriguez]

On Wed, Mar 11, 2015 at 10:36:41PM -0700, David Rientjes wrote:
> On Wed, 11 Mar 2015, Luis R. Rodriguez wrote:
> 
> > From: "Luis R. Rodriguez" <mcgrof@xxxxxxxx>
> > 
> > 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
> > 
> 
> 1.6% increase.

Indeed, but we are talking about x86-32 bit and the question these
two patches bring up is -- is the gains of the cleanup from the
removal of these two worth the compromise? I think it is, but
if there is active interest in keeping 32-bit x86 builds tiny
I understand if this is not desirable.

> > [0] https://lkml.org/lkml/2015/1/22/718
> > 
> > Cc: David Rientjes <rientjes@xxxxxxxxxx>
> > Cc: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
> > Cc: Bryan O'Donoghue <pure.logic@xxxxxxxxxxxxxxxxx>
> > Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> > Cc: Andy Shevchenko <andy.shevchenko@xxxxxxxxx>
> > Cc: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
> > Cc: Ingo Molnar <mingo@xxxxxxxxxx>
> > Cc: Borislav Petkov <bp@xxxxxxx>
> > Cc: H. Peter Anvin <hpa@xxxxxxxxx>
> > Cc: Jan Beulich <JBeulich@xxxxxxxx>
> > Cc: Juergen Gross <jgross@xxxxxxxx>
> > Cc: linux-pci@xxxxxxxxxxxxxxx
> > Cc: x86@xxxxxxxxxx
> > Signed-off-by: Luis R. Rodriguez <mcgrof@xxxxxxxx>
> > ---
> >  arch/x86/Kconfig | 15 ++-------------
> >  1 file changed, 2 insertions(+), 13 deletions(-)
> > 
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index 110f6ae..b17a8ea 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -899,6 +899,7 @@ config X86_UP_APIC
> >  	bool "Local APIC support on uniprocessors" if !PCI_MSI
> >  	default PCI_MSI
> >  	depends on X86_32 && !SMP && !X86_32_NON_STANDARD
> > +	select X86_IO_APIC
> >  	---help---
> >  	  A local APIC (Advanced Programmable Interrupt Controller) is an
> >  	  integrated interrupt controller in the CPU. If you have a single-CPU
> > @@ -909,18 +910,6 @@ config X86_UP_APIC
> >  	  performance counters), and the NMI watchdog which detects hard
> >  	  lockups.
> >  
> > -config X86_UP_IOAPIC
> > -	bool "IO-APIC support on uniprocessors"
> > -	depends on X86_UP_APIC
> > -	---help---
> > -	  An IO-APIC (I/O Advanced Programmable Interrupt Controller) is an
> > -	  SMP-capable replacement for PC-style interrupt controllers. Most
> > -	  SMP systems and many recent uniprocessor systems have one.
> > -
> > -	  If you have a single-CPU system with an IO-APIC, you can say Y here
> > -	  to use it. If you say Y here even though your machine doesn't have
> > -	  an IO-APIC, then the kernel will still run with no slowdown at all.
> > -
> >  config X86_LOCAL_APIC
> >  	def_bool y
> >  	depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC || PCI_MSI
> > @@ -928,7 +917,7 @@ config X86_LOCAL_APIC
> >  
> >  config X86_IO_APIC
> >  	def_bool y
> > -	depends on X86_LOCAL_APIC || X86_UP_IOAPIC
> > +	depends on X86_LOCAL_APIC
> >  	select IRQ_DOMAIN
> >  
> >  config X86_REROUTE_FOR_BROKEN_BOOT_IRQS
> 
> I think it would be best to remove the "select" so the "depends" for both 
> config options won't diverge in the future.  This should be equivalent, 
> right?

Do you mean remove the "select IRQ_DOMAIN" ? If so the "select" does not imply
"depends" though, it simply will peg it on if its own dependencies are met.

> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -909,18 +909,6 @@ config X86_UP_APIC
>  	  performance counters), and the NMI watchdog which detects hard
>  	  lockups.
>  
> -config X86_UP_IOAPIC
> -	bool "IO-APIC support on uniprocessors"
> -	depends on X86_UP_APIC
> -	---help---
> -	  An IO-APIC (I/O Advanced Programmable Interrupt Controller) is an
> -	  SMP-capable replacement for PC-style interrupt controllers. Most
> -	  SMP systems and many recent uniprocessor systems have one.
> -
> -	  If you have a single-CPU system with an IO-APIC, you can say Y here
> -	  to use it. If you say Y here even though your machine doesn't have
> -	  an IO-APIC, then the kernel will still run with no slowdown at all.
> -
>  config X86_LOCAL_APIC
>  	def_bool y
>  	depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC || PCI_MSI
> @@ -928,7 +916,7 @@ config X86_LOCAL_APIC
>  
>  config X86_IO_APIC
>  	def_bool y
> -	depends on X86_LOCAL_APIC || X86_UP_IOAPIC
> +	depends on X86_LOCAL_APIC || X86_UP_APIC
>  	select IRQ_DOMAIN
>  
>  config X86_REROUTE_FOR_BROKEN_BOOT_IRQS
> 
> And then the second patch adds a 3.8% increase on top of this (and the two 
> "select" statements in that patch shouldn't be necessary, both 
> X86_LOCAL_APIC and X86_IO_APIC are def_bool y for PCI_MSI configs).

This is one way to express that and the trick is the depends are carried over
this way.

>  If these are just cleanup patches, I'm not sure I understand why a
>  considerable kernel text size increase is worth it.

The patches pose the question if the cleanup of the removal of both
is worth the compromise to always enable thes two for PCI_MSI and remove
the option to enable/disable it on platform where the depends match out.
The later would also imply that platforms that need it will need to
ensure its components select them, but historically it seems we can
only deduce these both are required for PCI_MSI 32-bit platforms.

  Luis
--
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/