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@xxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
