All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.