>>>>> On Sat, 4 Mar 2006 23:33:04 +1100, Paul Mackerras <[email protected]> said:
>> > > Also I assume Atsushi-san did the patch because he saw a real problem?
>> >
>> > Yes, one which I also saw on PPC. The compiler (gcc-4) emits loads
>> > for jiffies, jiffies64 and wall_jiffies before storing the incremented
>> > jiffies64 value back.
>> >
>>
>> What was the effect of that?
paulus> The effect is that the first call to do_timer doesn't increment xtime.
paulus> This explains why the code I have to detect disagreements between
paulus> xtime and the time of day as computed from the timebase register was
paulus> finding a disagreement on the first tick, which I was scratching my
paulus> head over.
paulus> There may be other effects on architectures which use wall_jiffies to
paulus> detect lost timer ticks. We don't have that problem on PPC and we
paulus> don't use wall_jiffies in computing time of day.
Well, I found this problem during investigating an another MIPS
do_gettimeofday() bug which was fixed recently. It was:
lost = jiffies - wall_jiffies;
...
} else if (unlikely(lost))
usecs += lost * tick_usec;
The tick_usec should not be used here since it is based on USER_HZ.
It is 'usecs += lost * (USECS_PER_SEC /HZ)' now.
I wondered why this bug really affects gettimeofday() always though
the 'lost' should usually be 0. And finally I noticed the
jiffies/jiffies_64 optimization issue.
---
Atsushi Nemoto
-
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]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
