From: Ingo Molnar <mingo@kernel.org>
To: Len Brown <lenb@kernel.org>
Cc: x86@kernel.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, Len Brown <len.brown@intel.com>,
Borislav Petkov <bp@alien8.de>
Subject: Re: [PATCH 2/2] x86: speed cpu_up by quirking cpu_init_udelay
Date: Fri, 8 May 2015 09:51:11 +0200 [thread overview]
Message-ID: <20150508075111.GA5403@gmail.com> (raw)
In-Reply-To: <170f6f6e9ac4aa4d8ec1ed5000bee95463897337.1431066425.git.len.brown@intel.com>
* Len Brown <lenb@kernel.org> wrote:
> From: Len Brown <len.brown@intel.com>
>
> Modern processor familes are on a white-list to remove
> the costly cpu_init_udelay 10000. Unknown processor families
> get the traditional 10ms delay in cpu_up().
>
> This seemed more efficient than forcing modern processors
> to exhaustively search a black-list having all the old
> processor families that should have a 10ms delay.
> For not only are new processor familes infrequently added,
> the white list also allows a delay other than 0, if needed.
> static unsigned int init_udelay = UDELAY_10MS_DEFAULT;
>
> +static const struct x86_cpu_id init_udelay_ids[] = {
> + { X86_VENDOR_INTEL, 0x6, X86_MODEL_ANY, X86_FEATURE_ANY, 0 },
> + { X86_VENDOR_AMD, 0x16, X86_MODEL_ANY, X86_FEATURE_ANY, 0 },
> + { X86_VENDOR_AMD, 0x15, X86_MODEL_ANY, X86_FEATURE_ANY, 0 },
> + { X86_VENDOR_AMD, 0x14, X86_MODEL_ANY, X86_FEATURE_ANY, 0 },
> + { X86_VENDOR_AMD, 0x12, X86_MODEL_ANY, X86_FEATURE_ANY, 0 },
> + { X86_VENDOR_AMD, 0x11, X86_MODEL_ANY, X86_FEATURE_ANY, 0 },
> + { X86_VENDOR_AMD, 0x10, X86_MODEL_ANY, X86_FEATURE_ANY, 0 },
> + { X86_VENDOR_AMD, 0xF, X86_MODEL_ANY, X86_FEATURE_ANY, 0 },
> + {}
> +};
So since especially AMD likes to iterate the family upwards, why not
make this a simple open ended check:
if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
boot_cpu_data.x86 >= 6 ||
boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
boot_cpu_data.x86 >= 15) {
... 0 delay ...
}
... which is much smaller and more future proof?
Thanks,
Ingo
next prev parent reply other threads:[~2015-05-08 7:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-08 6:37 [PATCH 0/2 v2] speeding up cpu_up() Len Brown
2015-05-08 6:37 ` [PATCH 1/2] x86: replace cpu_up hard-coded mdelay with variable udelay Len Brown
2015-05-08 6:37 ` [PATCH 2/2] x86: speed cpu_up by quirking cpu_init_udelay Len Brown
2015-05-08 7:51 ` Ingo Molnar [this message]
2015-05-08 8:23 ` Borislav Petkov
2015-05-08 8:32 ` Borislav Petkov
2015-05-08 18:15 ` Len Brown
2015-05-08 18:27 ` Borislav Petkov
2015-05-09 7:22 ` Ingo Molnar
2015-05-09 7:24 ` Ingo Molnar
2015-05-09 8:04 ` Borislav Petkov
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=20150508075111.GA5403@gmail.com \
--to=mingo@kernel.org \
--cc=bp@alien8.de \
--cc=len.brown@intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--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.