Messages in this thread | | | Date | Sun, 05 Mar 2006 01:43:38 +0900 (JST) | Subject | Re: [PATCH] simplify update_times (avoid jiffies/jiffies_64 aliasing problem) | From | Atsushi Nemoto <> |
| |
>>>>> On Sat, 4 Mar 2006 23:33:04 +1100, Paul Mackerras <paulus@samba.org> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |