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

[John Stultz]

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/