On Thu, 15 Nov 2012, John Stultz wrote:
> 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.. :)
Fair enough!
> > 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.
Ok. We probably should add the missing ones to the VDSO then.
Thanks,
tglx
--
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
