Re: [PATCH RFC V2 3/6] time: keep track of the pending utc/tai threshold

From: John Stultz
Date: Wed May 23 2012 - 12:52:07 EST


On 05/23/2012 01:29 AM, Richard Cochran wrote:
On Tue, May 22, 2012 at 11:06:09AM -0700, John Stultz wrote:
It seems currently we have:

U CODE T
----------------
9 INS 1
----------------
10 INS 1 pre tick, post leap second edge (this is the technically incorrect interval)
~~~~~~~~~~~~~~~~
9 OOP 2 post tick, post leap second edge
----------------
10 WAIT 2 new epoch


If you're trying to correct the pre-tick, post leap second edge, the above provides all you need.

In the adjtimex code, all you have to do is:


if (unlikely(CODE == INS&& U == 10))

/*note, we're not modifying state here, just returning corrected local values*/

return (U-1, OOP, T+1);

return (U,CODE, T);
Okay, if you want it that way, then you will have to add the other
cases. For example:

switch (code) {
case INS:
if (U == epoch) {
U--;
T++;
code = OOP;
}
break;
case OOP:
if (U == epoch) {
epoch + 1 here, right?
code = WAIT;
}
break;
case DEL:
if (U == epoch - 1) {
U++;
T--;
code = WAIT;
}
break;
default:
break;
}
return (U, code, T);

This is beginning to look a lot like the code in my patch. However,
your approach is somewhat simpler, because it assumes the tick will
never miss a second overflow.

I'm a little unclear on the above, because it looks like you're modifying the state from the reader.


Since when the tick triggers, we'll move the CODE state appropriately.

Or am I still missing something?
Considering the tickless options, is it safe to assume that the CODE
state update will never be an entire second too late? If so, then
I'll rework the patch as above. If not, then I think the patch I
posted already handles all the cases.


I still don't think it matters. If we know the when next leap second is supposed to be, if the time_state is INS, then we can still handle things without extra state.

if (unlikely(CODE == INS&& U == next_leap))
return (U-1, OOP, T+1);

if (unlikely(CODE == INS&& U == next_leap + 1))
return (U-1, WAIT, T+1);

if (unlikely(CODE == DEL&& U == next_leap - 1))
return (U+1, WAIT, T-1);


So even if we somehow sleep for two seconds over the leap second, and then an application hits the read critical section before the timer interrupt comes in the update the state, we can still provide correct state transition in the reader.

Thus the only additional state you might need over what we already have is the next_leap value.

thanks
-john

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/