From: Yinghai Lu <yinghai@kernel.org>
To: Ravikiran G Thirumalai <kiran@scalex86.org>,
Ingo Molnar <mingo@elte.hu>,
Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
shai@scalex86.org
Subject: Re: [PATCH] x86: don't compile vsmp_64 for 32bit
Date: Mon, 02 Mar 2009 16:08:26 -0800 [thread overview]
Message-ID: <49AC74FA.3010206@kernel.org> (raw)
In-Reply-To: <20090302235120.GF27240@localdomain>
Ravikiran G Thirumalai wrote:
> On Sat, Feb 28, 2009 at 10:44:30AM +0100, Ingo Molnar wrote:
>> * Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
>>
>>> True, but by how much? 212 bytes, out of 7285943 bytes which
>>> is very very small percentage wise.
>> How does this eliminate the validity of the patch?
>>
>
> It costs 212 bytes to leave is_vsmp_box() to not just be a dummy no-op.
> Having is_vsmp_box() detect if the hardware is indeed vSMP, is meaningful even when
> CONFIG_VSMP is not turned on. This is because is_vsmp_box() is used to
> tell the kernel, that although the cpus being used are supposed to have TSCs
> in sync, they are not really in sync. This is because
> you cannot ensure TSCs won't drift between multiple boards being aggregated
> on vSMP systems. Take the case of distro kernels. Distro kernels typically do
> not have CONFIG_X86_VSMP on. Due to the large internode cacheline
> setting, CONFIG_VSMP would not be on on the generic distro installer kernels.
> If is_vsmp_box() is a no-op, the generic distro installer kernels will
> assume TSCs to be synched, which is bad. Hence, it will be nice if, for
> the cost of 212 bytes, vsmp64.o be compiled either unconditionally, OR
> conditionally for 64bit architectures only. The question is, is 212 bytes out
> of 7285943 bytes too expensive for the generic kernels? I hope not.
we may need to revisit apic_is_clustered_box()
/*
* apic_is_clustered_box() -- Check if we can expect good TSC
*
* Thus far, the major user of this is IBM's Summit2 series:
*
* Clustered boxes may have unsynced TSC problems if they are
* multi-chassis. Use available data to take a good guess.
* If in doubt, go HPET.
*/
__cpuinit int apic_is_clustered_box(void)
....
/*
* If clusters > 2, then should be multi-chassis.
* May have to revisit this when multi-core + hyperthreaded CPUs come
* out, but AFAIK this will work even for them.
*/
with intel new cpus with 8 cores and HT enabled, even 2 sockets system will get 3 (?) so called "apic cluster"
we really need to use dmi etc way to detect multi-chassis system from now on
YH
next prev parent reply other threads:[~2009-03-03 0:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-26 5:20 [PATCH] x86: don't compile vsmp_64 for 32bit Yinghai Lu
2009-02-26 5:40 ` Ingo Molnar
2009-02-26 6:48 ` Ravikiran G Thirumalai
2009-02-26 8:39 ` Yinghai Lu
2009-02-26 11:44 ` Ingo Molnar
2009-02-27 0:17 ` Ravikiran G Thirumalai
2009-02-28 9:44 ` Ingo Molnar
2009-03-02 23:51 ` Ravikiran G Thirumalai
2009-03-03 0:08 ` Yinghai Lu [this message]
2009-03-22 12:48 ` Ingo Molnar
2009-03-24 6:14 ` Ravikiran G Thirumalai
2009-03-24 9:10 ` Ingo Molnar
2009-03-25 18:51 ` Ravikiran G Thirumalai
2009-03-25 22:16 ` Jeremy Fitzhardinge
2009-03-25 22:36 ` Ravikiran G Thirumalai
2009-03-25 23:15 ` Jeremy Fitzhardinge
2009-03-25 23:29 ` Ravikiran G Thirumalai
2009-03-25 23:36 ` Thomas Gleixner
2009-03-26 0:11 ` Ravikiran G Thirumalai
2009-03-25 23:58 ` Jeremy Fitzhardinge
2009-03-26 0:31 ` Ravikiran G Thirumalai
2009-03-26 9:11 ` Ingo Molnar
2009-03-26 18:17 ` Ravikiran G Thirumalai
2009-03-26 7:57 ` [tip:x86/apic] Revert "x86: don't compile vsmp_64 for 32bit" Ravikiran G Thirumalai
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=49AC74FA.3010206@kernel.org \
--to=yinghai@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=kiran@scalex86.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=shai@scalex86.org \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
/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