On Mon, 1 Aug 2005, Bjorn Helgaas wrote:
> > If it is really synchronized then you can run with "nojitter" without any
> > issue. Then you wont have to deal with the cmpxchg and everything is fine.
> > But I suspect that the ITC are NOT truly synchronized (it has an
> > "offset" that may be non
On Saturday 30 July 2005 12:10 pm, Christoph Lameter wrote:
> On Sat, 30 Jul 2005, Alex Williamson wrote:
>
> > On Fri, 2005-07-29 at 16:31 -0700, Christoph Lameter wrote:
> > > What you are dealing with is a machine that is using ITC as a time bases.
> > > That is a special case.
> >
> >The
On Sun, 31 Jul 2005, Alex Williamson wrote:
>Ok, here's an optimization that should help reduce contention on the
> cmpxchg, has zero impact on the nojitter path, and doesn't require any
> changes to fsys. When a caller already had the xtime_lock write lock
> there's no need to fight with oth
Ok, here's an optimization that should help reduce contention on the
cmpxchg, has zero impact on the nojitter path, and doesn't require any
changes to fsys. When a caller already had the xtime_lock write lock
there's no need to fight with other CPUs for the cmpxchg. The other
"reader" CPUs wi
On Sat, 30 Jul 2005, Alex Williamson wrote:
> On Fri, 2005-07-29 at 16:31 -0700, Christoph Lameter wrote:
> > What you are dealing with is a machine that is using ITC as a time bases.
> > That is a special case.
>
>The default time source for ia64 systems is a "special case"? 4
> socket and
On Fri, 2005-07-29 at 16:31 -0700, Christoph Lameter wrote:
> What you are dealing with is a machine that is using ITC as a time bases.
> That is a special case.
The default time source for ia64 systems is a "special case"? 4
socket and smaller boxes typically do not have any other time sourc
> diff --git a/include/linux/timex.h b/include/linux/timex.h
Oh. Before I forget: You need to make the same changes to the asm code in
arch/ia64/kernel/fsys.S in order for this to work properly. The asm code
has been optimized to the hilt to save every cycle possible. Please dont
add any. The C
What you are dealing with is a machine that is using ITC as a time bases.
That is a special case. The fix should not affect machines that have a
proper time source. More below. You can circumvent the compensation for
ITC inaccuracies by specifying "nojitter" on the kernel command if you are
wil
This loop in time_interpolator_get_counter():
do {
lcycle = time_interpolator->last_cycle;
now = time_interpolator_get_cycles(src);
if (lcycle && time_after(lcycle, now))
return
9 matches
Mail list logo
