Re: Detecting shift of CLOCK_REALTIME with clock_nanosleep (again)

[John Stultz <johnstul@us.ibm.com>]

On 11/15/2012 01:01 PM, Thomas Gleixner wrote:
> On Thu, 15 Nov 2012, John Stultz wrote:
>> On 11/15/2012 11:28 AM, Scot Salmon wrote:
>>> Thomas Gleixner <tglx@linutronix.de> wrote on 10/31/2012 03:08:45 PM:
>>>> What you are concerned about is keeping the machines in sync on a
>>>> common global timeline. Though your more fundamental requirement is
>>>> that you get the wakeup on each machine in the given cycle time. The
>>>> global synchronization mechanism just adjusts that local periodic
>>>> schedule.
>>> [...]
>>>> What you really want is an atomic readout facility for CLOCK_MONOTONIC
>>>> and CLOCK_REALTIME. That allows you to align the CLOCK_MONOTONIC based
>>>> timer with the global CLOCK_REALTIME based time line and in the event
>>>> that the CLOCK_REALTIME clock was set and jumped forward/backward you
>>>> have full software control over the aligning mechanism including the
>>>> ability to do sanity checking.
>>> This works for me.  We discussed it on IRC and agreed on "something
>>> like clock_gettime2(id, id, *t1, *t2) with a sanity check on the ids,
>>> that allows us other combinations than MONO/REAL as well".
>> Yea, there's been a few times that folks have brought up the need, and this
>> sort of interface is probably the best way to go.
>>
>> I suspect clock_gettime3 isn't far behind though :)
> I guess you are talking about MONO/MONORAW/REAL.
Or MONO/BOOT/REAL  or eventually MONO/TAI/REAL, etc..

But there's probably someone out there who will want all kernel state 
exported atomically, and its just not reasonable.

The real problem is that figuring out the relationship between clocks 
has required the three read interpoloation, which isn't something easily 
or quickly done with good accuracy. If we provide clock_gettime2(), that 
will allow the relationship between clockid pairs to be accurately 
determined. And if folks need to calculate the relationship between 
three clockids, they can do a similar three read and bound the output.
ie:
do {
     clock_gettime2(MONO, REAL, mon1,real1);
     clock_gettime2(MONO,BOOT, mon2,boot2);
     clock_gettime2(MONO,REAL, mon3, real3);
} while( real1-mon1 != real3-mon3);

So it might be over-designing to provide a clock_gettime3 from the start 
(since then folks will want clock_gettime5.. :)

>   So if you already
> know about such requirements we should go for that, but we should try
> to restrict it to combinations which can be easily supported in the
> VDSO as well.
Other then the cputime clockids, I'm not sure I see what combinations 
wouldn't work with the vdso.
As long as the clocksource is accessible, everything else is exportable.


thanks
-john