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
willing to take the risk of slightly inaccurate time.
On Fri, 29 Jul 2005 [email protected] wrote:
> The patch below makes things less bad by not letting Y & Z do the cmpxchg if
> they are going to fail the read_seqretry() test anyway. But it is very ugly
> to do this extra test on xtime_lock ... so I'm hoping that someone can come
> up with something better.
Well get a proper time source and do not use ITC for a time source in an
SMP system. Got HPET hardware?
> -extern unsigned long time_interpolator_get_offset(void);
> +extern unsigned long time_interpolator_get_offset(long);
This is going to cause unnecessary overhead for non ITC users.
> - nsec = xtime.tv_nsec+time_interpolator_get_offset();
> + nsec = xtime.tv_nsec+time_interpolator_get_offset(seq);
Here it is.
> - offset = time_interpolator_get_offset();
> + offset = time_interpolator_get_offset(seq);
and here again.
> + /*
> + * If our caller is going to ignore us and retry, then
> + * don't burn up the bus with the cmpxchg
> + */
> + if (seq && unlikely(read_seqretry(&xtime_lock, seq)))
> + return now;
Two read_seqretries() for one read_seqbegin()? That its unusual to say
the least.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |