From: Ingo Molnar <mingo@elte.hu>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Andrew Morton <akpm@linux-foundation.org>,
Suresh Siddha <suresh.b.siddha@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86: enable x2apic early at the first point
Date: Fri, 20 Feb 2009 10:51:27 +0100 [thread overview]
Message-ID: <20090220095127.GK24555@elte.hu> (raw)
In-Reply-To: <499DD40F.40102@kernel.org>
* Yinghai Lu <yinghai@kernel.org> wrote:
> Impact: fix bug.
>
> otherwise will get panic from early_acpi_boot_init()
> also make disable_x2apic global, so could use it it x2_apic_xxx.c
> and can get warning if preenabled system using nox2apic.
>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>
> ---
> arch/x86/kernel/apic/apic.c | 3 +--
> arch/x86/kernel/apic/x2apic_cluster.c | 5 ++++-
> arch/x86/kernel/apic/x2apic_phys.c | 5 ++++-
> arch/x86/kernel/apic/x2apic_uv_x.c | 4 +++-
> drivers/pci/dmar.c | 3 ++-
> 5 files changed, 14 insertions(+), 6 deletions(-)
I've applied it because it fixes a real bug, but this code
really needs a cleanup. Look at the repeat patterns:
> Index: linux-2.6/arch/x86/kernel/apic/x2apic_cluster.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/apic/x2apic_cluster.c
> +++ linux-2.6/arch/x86/kernel/apic/x2apic_cluster.c
> @@ -14,8 +14,11 @@ DEFINE_PER_CPU(u32, x86_cpu_to_logical_a
>
> static int x2apic_acpi_madt_oem_check(char *oem_id, char *oem_table_id)
> {
> - if (cpu_has_x2apic)
> + if (cpu_has_x2apic && !disable_x2apic) {
> + x2apic = 1;
> + enable_x2apic();
> return 1;
> + }
>
> return 0;
> }
> Index: linux-2.6/arch/x86/kernel/apic/x2apic_phys.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/apic/x2apic_phys.c
> +++ linux-2.6/arch/x86/kernel/apic/x2apic_phys.c
> @@ -21,8 +21,11 @@ early_param("x2apic_phys", set_x2apic_ph
>
> static int x2apic_acpi_madt_oem_check(char *oem_id, char *oem_table_id)
> {
> - if (cpu_has_x2apic && x2apic_phys)
> + if (cpu_has_x2apic && !disable_x2apic && x2apic_phys) {
> + x2apic = 1;
> + enable_x2apic();
> return 1;
> + }
>
> return 0;
> }
> Index: linux-2.6/arch/x86/kernel/apic/x2apic_uv_x.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/apic/x2apic_uv_x.c
> +++ linux-2.6/arch/x86/kernel/apic/x2apic_uv_x.c
> @@ -41,8 +41,10 @@ static int uv_acpi_madt_oem_check(char *
> uv_system_type = UV_LEGACY_APIC;
> else if (!strcmp(oem_table_id, "UVX"))
> uv_system_type = UV_X2APIC;
> - else if (!strcmp(oem_table_id, "UVH")) {
> + else if (!strcmp(oem_table_id, "UVH") && !disable_x2apic) {
> uv_system_type = UV_NON_UNIQUE_APIC;
> + x2apic = 1;
> + enable_x2apic();
> return 1;
> }
> }
Such repeat patterns with small variations are always the sign
of an inefficient code structure.
The clean approach would be to have one generic helper function
concentrated into enable_x2apic(). So instead of:
static int x2apic_acpi_madt_oem_check(char *oem_id, char *oem_table_id)
{
if (cpu_has_x2apic && !disable_x2apic && x2apic_phys) {
x2apic = 1;
enable_x2apic();
return 1;
}
return 0;
}
We'd have:
static int x2apic_acpi_madt_oem_check(char *oem_id, char *oem_table_id)
{
if (!x2apic_phys)
return 0;
return x86_enable_x2apic();
}
That way all the repeat and common functionality (and the return
code logic) is concentrated into enable_x2apic(), and the
x2apic_acpi_madt_oem_check() function has _only_ its own special
check open-coded. (namely, whether physical ID delivery mode is
forced off.)
Okay?
Ingo
next prev parent reply other threads:[~2009-02-20 9:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-19 21:50 [PATCH] x86: enable x2apic early at the first point Yinghai Lu
2009-02-19 22:13 ` Suresh Siddha
2009-02-19 22:42 ` Yinghai Lu
2009-02-19 23:28 ` Suresh Siddha
2009-02-20 8:35 ` Ingo Molnar
2009-02-20 9:09 ` Gleb Natapov
2009-02-20 9:41 ` Ingo Molnar
2009-02-20 10:58 ` Gleb Natapov
2009-02-20 11:06 ` Ingo Molnar
2009-02-20 11:06 ` Gleb Natapov
2009-02-20 12:33 ` Gleb Natapov
2009-02-20 12:59 ` Ingo Molnar
2009-02-20 9:51 ` Ingo Molnar [this message]
2009-02-20 9:55 ` Ingo Molnar
2009-02-21 22:23 ` Suresh Siddha
2009-02-21 22:43 ` Yinghai Lu
2009-02-21 23:33 ` Suresh Siddha
2009-02-22 17:21 ` Ingo Molnar
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=20090220095127.GK24555@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
--cc=yinghai@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox