* Andi Kleen ([EMAIL PROTECTED]) wrote:
>
> > So if, after this, we run tsc_sched_clock() with an unstable TSC, we
> > read a last_val containing the interrupt's MSB and the last_val LSB. It
> > can particularity hurt if we are around a 32 bits overflow, because time
> > could "jump" forward of ab
> So if, after this, we run tsc_sched_clock() with an unstable TSC, we
> read a last_val containing the interrupt's MSB and the last_val LSB. It
> can particularity hurt if we are around a 32 bits overflow, because time
> could "jump" forward of about 1.43 seconds on a 3 GHz system.
>
> So I gues
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
> * Andi Kleen ([EMAIL PROTECTED]) wrote:
> >
> > > I noticed the same thing about interrupts off when going through the
> > > code.
> >
> > That's only on a slow path during cpu frequency changing while the TSC is
> > instable.
> > Shouldn't be tha
* Andi Kleen ([EMAIL PROTECTED]) wrote:
>
> > I noticed the same thing about interrupts off when going through the
> > code.
>
> That's only on a slow path during cpu frequency changing while the TSC is
> instable.
> Shouldn't be that common.
>
> -Andi
Hrm, I don't see why you can get away wit
> I noticed the same thing about interrupts off when going through the
> code.
That's only on a slow path during cpu frequency changing while the TSC is
instable.
Shouldn't be that common.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message t
* Nick Piggin ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers wrote:
>
> >I tried it with and without the LOCK prefix on my Pentium 4.
> >
> >Locked cmpxchg8b : 90 cycles
> >Non locked cmpxchg8b: 30 cycles
> >sti: 166 cycles
> >cli: 159 cycles
> >
> >So, hrm, even if we use the locked version, it i
Mathieu Desnoyers wrote:
I tried it with and without the LOCK prefix on my Pentium 4.
Locked cmpxchg8b : 90 cycles
Non locked cmpxchg8b: 30 cycles
sti: 166 cycles
cli: 159 cycles
So, hrm, even if we use the locked version, it is still much faster than
the sti/cli. I am thoughtful about the com
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
> I just want to rectify a detail: local_t uses type "long", which is 32
> bits on x86_32 and 64 bits on x86_64.
>
> Using a cmpxchg8b on i386 seems to require the LOCK prefix to be taken,
> so it may degrate performances too much. Therefore, you ma
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
> > > +/*
> > > + * Scheduler clock - returns current time in nanosec units.
> > > + * All data is local to the CPU.
> > > + * The values are approximately[1] monotonic local to a CPU, but not
> > > + * between CPUs. There might be also an occa
* Daniel Walker ([EMAIL PROTECTED]) wrote:
> On Thu, 2007-07-19 at 11:54 +0200, Andi Kleen wrote:
> > Move it into an own file for easy sharing.
> > Do everything per CPU. This avoids problems with TSCs that
> > tick at different frequencies per CPU.
> > Resync properly on cpufreq changes. CPU freq
On Thu, 2007-07-19 at 20:00 +0200, Andi Kleen wrote:
> On Thursday 19 July 2007 19:43:49 Daniel Walker wrote:
> > On Thu, 2007-07-19 at 19:38 +0200, Andi Kleen wrote:
> > > On Thursday 19 July 2007 19:31:56 Daniel Walker wrote:
> > >
> > > > >From my perspective a downside to sched_clock is that t
On Thursday 19 July 2007 19:43:49 Daniel Walker wrote:
> On Thu, 2007-07-19 at 19:38 +0200, Andi Kleen wrote:
> > On Thursday 19 July 2007 19:31:56 Daniel Walker wrote:
> >
> > > >From my perspective a downside to sched_clock is that the math is
> > > duplicated per architecture .. I think it woul
On Thu, 2007-07-19 at 19:38 +0200, Andi Kleen wrote:
> On Thursday 19 July 2007 19:31:56 Daniel Walker wrote:
>
> > >From my perspective a downside to sched_clock is that the math is
> > duplicated per architecture .. I think it would be a win to use the
> > generic functions if it's possible..
>
On Thursday 19 July 2007 19:31:56 Daniel Walker wrote:
> >From my perspective a downside to sched_clock is that the math is
> duplicated per architecture .. I think it would be a win to use the
> generic functions if it's possible..
They can't be used because they're not cpu local. The whole basi
On Thu, 2007-07-19 at 19:22 +0200, Andi Kleen wrote:
> On Thursday 19 July 2007 19:15:38 Daniel Walker wrote:
> > On Thu, 2007-07-19 at 19:13 +0200, Andi Kleen wrote:
> > > > What about using the cycles2ns() clocksource helpers, it would eliminate
> > > > the duplication of the shift/multiply math
On Thursday 19 July 2007 19:15:38 Daniel Walker wrote:
> On Thu, 2007-07-19 at 19:13 +0200, Andi Kleen wrote:
> > > What about using the cycles2ns() clocksource helpers, it would eliminate
> > > the duplication of the shift/multiply math .
> >
> > They are completely different from what clocksourc
On Thu, 2007-07-19 at 19:13 +0200, Andi Kleen wrote:
> > What about using the cycles2ns() clocksource helpers, it would eliminate
> > the duplication of the shift/multiply math .
>
> They are completely different from what clocksource provides.
How so?
Daniel
-
To unsubscribe from this list: se
> What about using the cycles2ns() clocksource helpers, it would eliminate
> the duplication of the shift/multiply math .
They are completely different from what clocksource provides.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA
On Thu, 2007-07-19 at 11:54 +0200, Andi Kleen wrote:
> Move it into an own file for easy sharing.
> Do everything per CPU. This avoids problems with TSCs that
> tick at different frequencies per CPU.
> Resync properly on cpufreq changes. CPU frequency is instable
> around cpu frequency changing, so
Move it into an own file for easy sharing.
Do everything per CPU. This avoids problems with TSCs that
tick at different frequencies per CPU.
Resync properly on cpufreq changes. CPU frequency is instable
around cpu frequency changing, so fall back during a backing
clock during this period.
Hopefull
20 matches
Mail list logo
