All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Lampert <scott@lampert.org>
To: "Langsdorf, Mark" <mark.langsdorf@amd.com>
Cc: john stultz <johnstul@us.ibm.com>, Andi Kleen <ak@suse.de>,
	Andrew Morton <akpm@osdl.org>,
	lkml <linux-kernel@vger.kernel.org>,
	discuss@x86-64.org
Subject: Re: [discuss] Re: [PATCH] x86-64: Fix bad assumption that dualcore cpus have synced TSCs
Date: Tue, 20 Sep 2005 12:24:20 -0700	[thread overview]
Message-ID: <433061E4.20903@lampert.org> (raw)
In-Reply-To: <84EA05E2CA77634C82730353CBE3A843032187C4@SAUSEXMB1.amd.com>

Langsdorf, Mark wrote:

>>On Mon, 2005-09-19 at 21:49 +0200, Andi Kleen wrote:
>>    
>>
>>>On Mon, Sep 19, 2005 at 12:42:16PM -0700, john stultz wrote:
>>>      
>>>
>>>>On Mon, 2005-09-19 at 21:31 +0200, Andi Kleen wrote:
>>>>        
>>>>
>>>>>On Mon, Sep 19, 2005 at 12:16:43PM -0700, john stultz wrote:
>>>>>          
>>>>>
>>>>>>	This patch should resolve the issue seen in 
>>>>>>            
>>>>>>
>>bugme bug #5105, 
>>    
>>
>>>>>>where it is assumed that dualcore x86_64 systems have synced 
>>>>>>TSCs. This is not the case, and alternate timesources 
>>>>>>            
>>>>>>
>>should be 
>>    
>>
>>>>>>used instead.
>>>>>>            
>>>>>>
>>>>>I asked AMD some time ago and they told me it was synchronized. 
>>>>>The TSC on K8 is C state invariant, but not P state 
>>>>>          
>>>>>
>>invariant, but 
>>    
>>
>>>>>P states always happen synchronized on dual cores.
>>>>>
>>>>>So I'm not quite convinced of your explanation yet.
>>>>>          
>>>>>
>>>>Would a litter userspace test checking the TSC 
>>>>        
>>>>
>>synchronization maybe 
>>    
>>
>>>>shed additional light on the issue?
>>>>        
>>>>
>>>Sure you can try it.
>>>      
>>>
>>So, bugzilla.kernel.org has (temporarily at least) lost the 
>>reports from yesterday, but from the email i got, folks using 
>>my TSC consistency check that I posted were seeing what 
>>appears to be unsynched TSCs on dualcore AMD systems.
>>    
>>
>
>My understanding was that each TSC on a dual-core processor
>will advance individually and atomically.  They will not 
>always be in synchronization.
>
>  
>
>>Personally I suspect that the powernow driver is putting the 
>>cores independently into low power sleep and the TSCs are 
>>being independently halted, causing them to become unsynchronized.
>>    
>>
>
>The powernow-k8 driver doesn't know what a low power sleep state
>is, so I strongly doubt it is involved here.  It only handles
>pstates.
> 
>-Mark Langsdorf
>K8 PowerNow! Maintainer
>AMD, Inc.
>
>  
>

Just to add some end-user input here, I see the same issues regardless 
of whether I'm running with the powernow-k8 or not.  The clock problems 
seem to be unrelated to that, at least on my system.
    -Scott

  reply	other threads:[~2005-09-20 19:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-20 19:13 [discuss] Re: [PATCH] x86-64: Fix bad assumption that dualcore cpus have synced TSCs Langsdorf, Mark
2005-09-20 19:24 ` Scott Lampert [this message]
2005-09-20 19:30   ` john stultz
  -- strict thread matches above, loose matches on Subject: below --
2005-09-19 19:16 john stultz
2005-09-19 19:31 ` Andi Kleen
2005-09-19 19:42   ` john stultz
2005-09-19 19:49     ` [discuss] " Andi Kleen
2005-09-20 18:59       ` john stultz
2005-09-21  4:03         ` Daniel Jacobowitz
2005-09-21 15:15           ` Ray Bryant
2005-09-21 15:04             ` Andi Kleen
2005-09-21 15:46               ` Ray Bryant
2005-09-22  8:00                 ` Jonas Oreland
2005-09-21 20:17               ` Andrew Morton
2005-10-07 12:26 ` Vladimir B. Savkin
2005-10-07 12:31   ` Andi Kleen
2005-10-07 14:15     ` Vladimir B. Savkin
2005-10-07 14:21       ` [discuss] " Velu Erwan

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=433061E4.20903@lampert.org \
    --to=scott@lampert.org \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=discuss@x86-64.org \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.langsdorf@amd.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 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.