Re: x86-64: Syncing dualcore cpus TSCs

[David Lang]

On Tue, 25 Oct 2005, Andi Kleen wrote:

> On Tuesday 25 October 2005 09:35, Jonas Oreland wrote:
> > Hi,
> >
> > This might be a very bad suggestion, but here it is:
> >
> > On dualcore cpus (amd64) the TSC will get out of sync when executing hlt
> > instruction. booting with idle=poll, will make it never to execute hlt,
> > hence TSC will be in sync. booting with notsc will make it use other time
> > source...but this is slower (this is default after "[PATCH] x86-64: Fix bad
> > assumption that dualcore cpus have synced TSCs")
> >
> > How about syncing TSC after hlt?
> >
> > If cost of syncing TSC's is smaller than cost of using other time source
> > this might be an alternative.
>
> I very doubt it is. Syncing TSCs requires stopping multiple CPUs for longer
> time. It is unlikely you can make that up.

I may be misunderstanding things, but as I understand it the reason for 
calling hlt is to save power.

if you really care about the last bit of performance then useing idle=poll 
to make the TSC's stay synced makes perfect sense.

it's cases where you care about saving power that you would want to use 
hlt. can the power management be reasonably configured so that when things 
are running close to full-bore hlt isn't called, when things are more idle 
it switches to useing hlt and a non-TSC timesource or re-syncing the TSC 
on wakeup, and then if it's more idle then that it goes into the more 
traditional power saving modes where it works to shutdown individual CPU's 
(obviously having to re-sync the TSC when they wake up).

David Lang

--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/