From: "Bryan O'Donoghue" <pure.logic@nexus-software.ie>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: mingo@redhat.com, davej@redhat.com, hpa@zytor.com,
hmh@hmh.eng.br, x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] x86: Bugfix bit-rot in the calling of legacy_cache_size
Date: Tue, 30 Sep 2014 22:02:44 +0100 [thread overview]
Message-ID: <542B1A74.9000909@nexus-software.ie> (raw)
In-Reply-To: <alpine.DEB.2.11.1409302211560.4455@nanos>
On 30/09/14 21:28, Thomas Gleixner wrote:
> On Tue, 30 Sep 2014, Bryan O'Donoghue wrote:
>> static void default_init(struct cpuinfo_x86 *c)
>> {
>> -#ifdef CONFIG_X86_64
>> cpu_detect_cache_sizes(c);
>> -#else
>> +
>> /* Not much we can do here... */
>> /* Check if at least it has cpuid */
>> if (c->cpuid_level == -1) {
>> @@ -79,7 +78,6 @@ static void default_init(struct cpuinfo_x86 *c)
>> else if (c->x86 == 3)
>> strcpy(c->x86_model_id, "386");
>> }
>> -#endif
>
> What's the exact point of this? This is the default init function
> which is for X86_VENDOR_UNKNOWN, right?
Correct
>> }
>>
>> static const struct cpu_dev default_cpu = {
>> @@ -874,6 +872,15 @@ static void identify_cpu(struct cpuinfo_x86 *c)
>> #endif
>>
>> /*
>> + * If c_x86_vendor != X86_VENDOR_UNKNOWN i.e. a known vendor then
>> + * there's a vendor specific c_init()
>> + *
>> + * Even still Intel, AMD and VIA make use of legacy_cache_size which
>> + * is reachable only through default_init right now
>
> That's nonsense. It's called from cpu_detect_cache_sizes() and that is
> called from:
>
> arch/x86/kernel/cpu/amd.c: cpu_detect_cache_sizes(c);
> arch/x86/kernel/cpu/centaur.c: cpu_detect_cache_sizes(c);
> arch/x86/kernel/cpu/common.c: cpu_detect_cache_sizes(c);
> arch/x86/kernel/cpu/cyrix.c: cpu_detect_cache_sizes(c);
> arch/x86/kernel/cpu/transmeta.c: cpu_detect_cache_sizes(c);
/uses grep
Yes I see for everybody except Intel that'll get called. I mised that.
> So we have 4 callsites outside of default_init() already. Now you're
> adding another one into identify_cpu()
>
>> + */
>> + if (this_cpu->c_x86_vendor != X86_VENDOR_UNKNOWN)
>> + default_init(c);
>
> With the consequence that for amd/centaur/cyrix/transmeta
> cpu_detect_cache_sizes() is invoked twice for nothing.
Yes - I see what's needed here is for cpu_detect_cache_sizes to get
called for Intel only - so the bit rot is really only limited to
1. PIII Tualatin
2. New Intel additions on this path like Quark
> So the only CPU vendor c_init() callback which does not call
> cpu_detect_cache_sizes() is the Intel one. And therefor we inflict
> that call on all others twice. Brilliant solution!
Haha. When you put it like that you make it sound mad and unreasonable.
> So the proper solution is to add the call to identify_cpu()
> unconditionally and remove it from _all_ other call sites, make it
> static and be done with it.
Agree I'll make that update.
Thanks for your review.
--
BOD
next prev parent reply other threads:[~2014-09-30 21:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-30 3:11 [PATCH 0/3] Quark X1000 Cache/TLB reporting/fixes Bryan O'Donoghue
2014-09-30 3:11 ` [PATCH 1/3] x86: Bugfix bit-rot in the calling of legacy_cache_size Bryan O'Donoghue
2014-09-30 3:41 ` Dave Jones
2014-09-30 8:45 ` Bryan O'Donoghue
2014-09-30 20:28 ` Thomas Gleixner
2014-09-30 21:02 ` Bryan O'Donoghue [this message]
2014-09-30 3:11 ` [PATCH 2/3] x86: Quark: Update cache reporting, add Quark SoC X1000 string Bryan O'Donoghue
2014-09-30 19:38 ` Thomas Gleixner
2014-09-30 3:11 ` [PATCH 3/3] x86: Quark: Comment setup_arch for TLB/PGE bugfix Bryan O'Donoghue
2014-09-30 20:03 ` Thomas Gleixner
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=542B1A74.9000909@nexus-software.ie \
--to=pure.logic@nexus-software.ie \
--cc=davej@redhat.com \
--cc=hmh@hmh.eng.br \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome