Messages in this thread | | | From | Michał Cłapiński <> | Date | Thu, 21 Sep 2023 18:39:25 +0200 | Subject | Loosening time namespace restrictions |
| |
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ł
| |