Re: Ktimer / -rt9 (+custom) monotonic_clock going backwards.

[Steven Rostedt <rostedt@goodmis.org>]

Slightly different issue.

I just ran hackbench as a high priority process (higher than the tasklets)
and it once again has sys_gettimeofday going backwards.  It runs for 30
seconds, hogging the CPU from all other processes, and the gettimeofday
once again overflows.  This time it's more complex than then last time
because of the changes (I guess John) made.

Following the code into sys_gettimeofday, I end up at __get_nsec_offset.

static inline nsec_t __get_nsec_offset(void)
{
	cycle_t cycle_now, cycle_delta;
	nsec_t ns_offset;

	/* read clocksource */
	cycle_now = read_clocksource(clock);

	/* calculate the delta since the last timeofday_periodic_hook */
	cycle_delta = (cycle_now - cycle_last) & clock->mask;

	/* convert to nanoseconds */
	ns_offset = cyc2ns(clock, ntp_adj, cycle_delta);

	/* Special case for jiffies tick/offset based systems
	 * add arch specific offset
	 */
	ns_offset += arch_getoffset();

	return ns_offset;
}

cycle_now is 32 bits.  If the clocksource overflows (which it can in 30
seconds) the cyclec_delta will be wrong.

Not only this, but pretty much all places cycle_last is updated will be
wrong.

I'm not sure of a good fix around this. Please don't say (well, don't run
with priority above timers tasklet ;-)

Would it be OK to move some of the accounting to the sched_tick code. Or
someplace that only happens periodically.  Or is this too much of a
latency.  But then again, if we don't do something, a high priority
process can screw up the time keeping for all others.

-- Steve

-
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/