[CRIU] Setting monotonic time?

Thomas Gleixner tglx at linutronix.de
Tue Oct 2 09:16:38 MSK 2018


On Mon, 1 Oct 2018, Andrey Vagin wrote:
> On Mon, Oct 01, 2018 at 11:15:32AM +0200, Eric W. Biederman wrote:
> > 
> > In the context of process migration there is a simpler subproblem that I
> > think it is worth exploring if we can do something about.
> > 
> > For a cluster of machines all running with synchronized
> > clocks. CLOCK_REALTIME matches. CLOCK_MONOTNIC does not match between
> > machines.   Not having a matching CLOCK_MONOTONIC prevents successful
> > process migration between nodes in that cluster.
> > 
> > Would it be possible to allow setting CLOCK_MONOTONIC at the very
> > beginning of time?  So that all of the nodes in a cluster can be in
> > sync?
> 
> Here is a question about how to synchronize clocks between nodes. It
> looks like we will need to have a working network for this, but a
> network configuration may be non-trivial and it can require to run a few
> processes which can use CLOCK_MONOTNIC...
> 
> > 
> > No change in skew just in offset for CLOCK_MONOTONIC.
> > 
> > There are also dragons involved in coordinating things so that
> > CLOCK_MONOTONIC gets set before CLOCK_MONOTONIC gets used.  So I don't
> > know if allowing CLOCK_MONOTONIC to be set would be practical but it
> > seems work exploring all on it's own.
> > 
> > Dmitry would setting CLOCK_MONOTONIC exactly once at boot time solve
> > your problem that is you are looking at a time namespace to solve?
> 
> Process migration is only one of use-cases. Another use-case is
> restoring from snapshots. It may be even more popular than process
> migration. We can't guarantee that all snapshots will be done in one
> cluster. For example, a user meets a bug, does a container snapshot and
> attaches it to a bug report.

Sure, but see my reply to Eric. That could be solved with that extra clock
id, which then gets mapped to monotonic for name spaces.

Thanks,

	tglx


More information about the CRIU mailing list