Message-ID: <87lecqdlbw.ffs@tglx>
Date:   Thu, 28 Sep 2023 23:44:35 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Michał Cłapiński <mclapinski@...gle.com>,
        linux-kernel@...r.kernel.org
Cc:     John Stultz <jstultz@...gle.com>, Stephen Boyd <sboyd@...nel.org>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        Andy Lutomirski <luto@...nel.org>,
        Dmitry Safonov <0x7f454c46@...il.com>,
        Andrei Vagin <avagin@...nvz.org>
Subject: Re: Loosening time namespace restrictions

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

Powered by blists - more mailing lists