From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
rientjes@google.com, bhelgaas@google.com, mingo@redhat.com,
tglx@linutronix.de, hpa@zytor.com, jgross@suse.com,
luto@amacapital.net, andy.shevchenko@gmail.com,
thomas.petazzoni@free-electrons.com, JBeulich@suse.com,
bp@suse.de, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, x86@kernel.org,
Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH v1 1/2] x86: kconfig: remove X86_UP_IOAPIC
Date: Thu, 12 Mar 2015 16:35:35 +0100 [thread overview]
Message-ID: <20150312153535.GN25035@wotan.suse.de> (raw)
In-Reply-To: <5500E992.60505@nexus-software.ie>
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
next prev parent reply other threads:[~2015-03-12 15:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-11 23:10 [PATCH v1 0/2] x86: simplify UP APIC conditions Luis R. Rodriguez
2015-03-11 23:10 ` [PATCH v1 1/2] x86: kconfig: remove X86_UP_IOAPIC Luis R. Rodriguez
2015-03-12 1:19 ` Bryan O'Donoghue
2015-03-12 15:35 ` Luis R. Rodriguez [this message]
2015-03-12 5:36 ` David Rientjes
2015-03-12 15:26 ` Luis R. Rodriguez
2015-03-11 23:10 ` [PATCH v1 2/2] x86: kconfig: remove X86_UP_APIC Luis R. Rodriguez
2015-03-12 8:42 ` Jan Beulich
[not found] ` <55015F690200007800068D86@suse.com>
2015-03-12 15:18 ` Luis R. Rodriguez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150312153535.GN25035@wotan.suse.de \
--to=mcgrof@suse.com \
--cc=JBeulich@suse.com \
--cc=andy.shevchenko@gmail.com \
--cc=bhelgaas@google.com \
--cc=bp@suse.de \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mcgrof@do-not-panic.com \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=pure.logic@nexus-software.ie \
--cc=rientjes@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.petazzoni@free-electrons.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.