Loosening time namespace restrictions

Loosening time namespace restrictions

[Michał Cłapiński]

Hello,
I faced a problem with the current implementation of time ns while
using it for container migration. I'd like users of CLOCK_MONOTONIC to
notice as small of a jump as possible in the clock after migration,
since according to the documentation "this clock does not count time
that the system is suspended". In that case the formula for clock
monotonic offset is "m1_monotonic - m2_monotonic - migration_downtime"
where m<n>_monotonic is clock monotonic value on the n-th machine.
Unfortunately due to time ns restrictions, I have to set the offsets
before putting any process in the namespace. I also can't move
multithreaded processes between namespaces. So I would have to know
the migration downtime before the migration is close to done, which
seems impossible. For that reason I'd like to drop the requirement of
having to set the offsets before putting any processes in the
namespace. What do you think? Is it possible to implement this and get
it merged or should I forgo it? If you think it's possible, I'd
appreciate any pointers on how to get this done (or how to solve my
problem in another way).

Thanks,
Michał

Re: Loosening time namespace restrictions

[Andrey Vagin]

On Fri, Sep 22, 2023 at 5:51 AM Michał Cłapiński <mclapinski@google.com> wrote:
>
> Hello,
> I faced a problem with the current implementation of time ns while
> using it for container migration. I'd like users of CLOCK_MONOTONIC to
> notice as small of a jump as possible in the clock after migration,
> since according to the documentation "this clock does not count time
> that the system is suspended". In that case the formula for clock
> monotonic offset is "m1_monotonic - m2_monotonic - migration_downtime"
> where m<n>_monotonic is clock monotonic value on the n-th machine.
> Unfortunately due to time ns restrictions, I have to set the offsets
> before putting any process in the namespace. I also can't move
> multithreaded processes between namespaces. So I would have to know
> the migration downtime before the migration is close to done, which
> seems impossible. For that reason I'd like to drop the requirement of
> having to set the offsets before putting any processes in the
> namespace. What do you think? Is it possible to implement this and get
> it merged or should I forgo it? If you think it's possible, I'd
> appreciate any pointers on how to get this done (or how to solve my
> problem in another way).

It was one of the requirements to disallow offset changes if there are
tasks in a target namespace. I didn't remember who made it up, but it
looks reasonable to me even now. The main idea of it is to minimize side
effects and to make the code as simple as possible.

If we want to change this, we need to think about a few things:
* what should we do with timers when offsets are changed?
* synchronization. Right now, when offsets are changed, there are no
  readers, so we don't need to use any locks, atomics, etc. The
  performance of vdso clock_gettime was one of the major concerns.
  In this case, we need to think about it too.
* when offsets are changed, monotonic clocks can jump backward for
  processes inside a namespace.
* There may be a few other things that I missed.

Thanks,
Andrei

Re: Loosening time namespace restrictions

[Thomas Gleixner]

On Thu, Sep 21 2023 at 18:39, Michał Cłapiński wrote:
> I faced a problem with the current implementation of time ns while
> using it for container migration. I'd like users of CLOCK_MONOTONIC to
> notice as small of a jump as possible in the clock after migration,
> since according to the documentation "this clock does not count time
> that the system is suspended". In that case the formula for clock
> monotonic offset is "m1_monotonic - m2_monotonic - migration_downtime"
> where m<n>_monotonic is clock monotonic value on the n-th machine.
> Unfortunately due to time ns restrictions, I have to set the offsets
> before putting any process in the namespace. I also can't move
> multithreaded processes between namespaces. So I would have to know
> the migration downtime before the migration is close to done, which
> seems impossible. For that reason I'd like to drop the requirement of
> having to set the offsets before putting any processes in the
> namespace. What do you think? Is it possible to implement this and get
> it merged or should I forgo it? If you think it's possible, I'd
> appreciate any pointers on how to get this done (or how to solve my
> problem in another way).

Lots of word salad. Seems your newline key has an issue. Let me split
that up for you.

> I faced a problem with the current implementation of time ns while
> using it for container migration.
>
> I'd like users of CLOCK_MONOTONIC to notice as small of a jump as
> possible in the clock after migration, since according to the
> documentation "this clock does not count time that the system is
> suspended".

"I'd like" is not a technical term and the documentation reference
to what clock MONOTONIC represents does not help either.

> In that case the formula for clock monotonic offset is "m1_monotonic -
> m2_monotonic - migration_downtime" where m<n>_monotonic is clock
> monotonic value on the n-th machine.

I which case? 

> Unfortunately due to time ns restrictions, I have to set the offsets
> before putting any process in the namespace.

That's obvious because how would you guarantee that the process cannot
observe the wrong time or does not expire timers early?

> I also can't move multithreaded processes between namespaces.

I have no idea what you are trying to tell me here.

  1) What has this to do with multi-threading?

     Are you suggesting that having thread A of a process to be in a
     different time domain than thread B of a process is something
     useful?

     Seriously this does not make any sense at all and if you think
     that's something useful then you completely failed to explain the
     use case.
 
  2) How does moving a process from a time namespace A to a time
     namespace B make sense at all?

     That's simply impossible unless time namespace A and time namespace
     B are identical. Otherwise you screw up time readouts and armed
     timers in one go. If they are identical then there is no point to
     move it, right?

     Aside of that you fail again to describe which problem you are
     trying to solve.

> So I would have to know the migration downtime before the migration is
> close to done, which seems impossible. For that reason I'd like to
> drop the requirement of having to set the offsets before putting any
> processes in the namespace.

How do you guarantee that the process cannot observe time going
backwards and timers firing early when you set the offset after you
restored the process into the time name space and resumed it?

The answer is: Not at all. 

> What do you think? Is it possible to implement this and get it merged
> or should I forgo it? If you think it's possible, I'd appreciate any
> pointers on how to get this done (or how to solve my problem in
> another way).

I still have not figured out which problem you are trying to solve, so
giving advice would involve crystal balls. I misplaced mine and even if
I could find it again I'd refuse to use it for giving techical advice.

Thanks,

        tglx