public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ravikiran G Thirumalai <kiran@scalex86.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	Glauber de Oliveira Costa <gcosta@redhat.com>,
	shai@scalex86.org
Subject: Re: [patch 4/4] x86: apic_is_clustered_box to indicate unsynched TSC's on multiboard vSMP systems
Date: Fri, 21 Mar 2008 11:52:25 -0700	[thread overview]
Message-ID: <20080321185225.GA23139@localdomain> (raw)
In-Reply-To: <20080321091542.GE20420@elte.hu>

On Fri, Mar 21, 2008 at 10:15:42AM +0100, Ingo Molnar wrote:
>
>* Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
>
>> >>  -       if (!is_vsmp_box() && (boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
>> >>  +       if ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) && !is_vsmp_box())
>> >>                 return 0;
>
>> Yes.  The first call is to state that TSC's are synced if it is an AMD 
>> box and if it is _not_ a vSMPowered box (for the apic id lifting case 
>> on Sun boxes), the second call is for _any_ vSMPowered system with 
>> more than one board -- TSC's are not guaranteed to be synched in that 
>> case.  Both these calls are needed.
>
>i suspect there are two questions here: firstly, your change only flips 
>the condition around which should not have any effect _normally_. But 
>the thing is that is_vsmp_box() has side-effects: it reads the PCI 
>config space and sets a flag. It would be cleaner if there was a 
>separate, explicit detect_vsmp_box() call early during bootup which did 
>the PCI config space access, and is_vsmp_box() would only return the 
>current state of the vsmp flag. Then your above change would be 
>unnecessary.

The above change -- the flipping of conditions -- is not _really_ necessary.
The condition and call is needed however.  The flip was done while
experimenting with the patch, since most vSMPowered machines today are mostly
intel, the call to is_vsmp_box() could be avoided here on intel boxes.
However this is only a trivial micro-optimization, as, we call
is_vsmp_box() again even for intel boxes now.

As for the observation about probing the pci space early during the bootup,
we call vsmp_init() much earlier during the bootup, which calls is_vsmp_box(),
does the pci probing and caches the result in the flag,  as you suggest.
So the call in the above diff context does not access the pci config space
as is.

Thanks,
Kiran

  reply	other threads:[~2008-03-21 18:52 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-20  7:37 [patch 0/4] x86: vSMP updates Ravikiran G Thirumalai
2008-03-20  7:39 ` [patch 1/4] x86: vSMP: Fix is_vsmp_box() Ravikiran G Thirumalai
2008-03-20  7:44   ` Yinghai Lu
2008-03-20 18:40     ` Ravikiran G Thirumalai
2008-03-21  9:11       ` Ingo Molnar
2008-03-21  9:17         ` Yinghai Lu
2008-03-21 17:59         ` Ravikiran G Thirumalai
2008-03-20  7:41 ` [patch 2/4] x86: Fix build breakage when PCI is define and PARAVIRT is not Ravikiran G Thirumalai
2008-03-21  4:30   ` Jeremy Fitzhardinge
2008-03-21  6:28     ` Yinghai Lu
2008-03-21 18:54     ` Ravikiran G Thirumalai
2008-03-22  2:19       ` Jeremy Fitzhardinge
2008-03-20  7:43 ` [patch 3/4] x86: vSMP: Use pvops only if platform has the capability to support it Ravikiran G Thirumalai
2008-03-20  7:45 ` [patch 4/4] x86: apic_is_clustered_box to indicate unsynched TSC's on multiboard vSMP systems Ravikiran G Thirumalai
2008-03-20  7:53   ` Yinghai Lu
2008-03-20 19:02     ` Ravikiran G Thirumalai
2008-03-21  9:15       ` Ingo Molnar
2008-03-21 18:52         ` Ravikiran G Thirumalai [this message]
2008-03-21 18:58           ` Ingo Molnar
2008-03-22 18:59             ` Ravikiran G Thirumalai
2008-03-22 20:02               ` Ingo Molnar
2008-03-24 21:48                 ` Ravikiran G Thirumalai
2008-03-25 15:50                   ` Ingo Molnar
2008-03-21  8:54 ` [patch 0/4] x86: vSMP updates 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=20080321185225.GA23139@localdomain \
    --to=kiran@scalex86.org \
    --cc=akpm@linux-foundation.org \
    --cc=gcosta@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=shai@scalex86.org \
    --cc=yhlu.kernel@gmail.com \
    /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