On Tue, 2007-01-02 at 11:46 -0800, john stultz wrote: > On Mon, 2007-01-01 at 19:29 +0100, Roman Zippel wrote: > > On Wednesday 20 December 2006 02:54, john stultz wrote: > > > > > And here would be the follow on patch (again *untested*) for > > > CONFIG_NO_HZ slowing the time accumulation down to once per second. > > > > Changing it to one creates a potential problem with calling > > second_overflow().
Wait, at first I thought I understood this, but looking closer, I'm not so sure I do. > > It should be called every NTP_INTERVAL_FREQ times, but occasionally it's off Wait, so second_overflow should be called every NTP_INTERVAL_FREQ times (instead of every second)? Surely that's not right. > > by one (when xtime is close to a full second and the tick length is > > different > > from 1sec). At a higher frequency that's not much of a problem, but at one > > it > > means second_overflow() is occasionally called twice a second or skipped for > > a second. Usually the error should be quite small, but sometimes it can be > > significant. > > So in this case the loop in update_wall_time() should rather look like this: > > > > while (offset >= clock->cycle_interval) { > > ... > > second_overflow(); > > while (clock->xtime_nsec >= (u64)NSEC_PER_SEC << clock->shift) { > > clock->xtime_nsec -= (u64)NSEC_PER_SEC << clock->shift; > > xtime.tv_sec++; > > } > > ... > > } > > > > (Also note the change from "if" to "while".) This would assume that clock->cycle_interval would *always* be the length of a full second and that isn't what the patch trying to do. Maybe could you explain this some more? thanks -john - 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/