From: tglx at linutronix.de (Thomas Gleixner) Subject: [RFC 00/20] ns: Introduce Time Namespace Date: Mon, 29 Oct 2018 21:33:14 +0100 (CET) [thread overview] Message-ID: <alpine.DEB.2.21.1810292026040.5984@nanos.tec.linutronix.de> (raw) In-Reply-To: <20181021014121.GA23474@gmail.com> Andrei, On Sat, 20 Oct 2018, Andrei Vagin wrote: > When a container is migrated to another host, we have to restore its > monotonic and boottime clocks, but we still expect that the container > will continue using the host real-time clock. > > Before stating this series, I was thinking about this, I decided that > these cases can be solved independently. Probably, the full isolation of > the time sub-system will have much higher overhead than just offsets for > a few clocks. And the idea that isolation of the real-time clock should > be optional gives us another hint that offsets for monotonic and > boot-time clocks can be implemented independently. > > Eric and Tomas, what do you think about this? If you agree that these > two cases can be implemented separately, what should we do with this > series to make it ready to be merged? > > I know that we need to: > > * look at device drivers that report timestamps in CLOCK_MONOTONIC base. and CLOCK_BOOTTIME and that's quite a few. > * forbid changing offsets after creating timers There are more things to think about. What about interfaces which expose boot time or monotonic time in /proc? Aside of that (I finally came around to look at the series in more detail) I'm really unhappy about the unconditional overhead once the Time namespace config switch is enabled. This applies especially to the VDSO. We spent quite some time recently to squeeze a few cycles out of those functions and it would be a pity to pointlessly waste cycles for the !namespace case. I can see the urge for this, but please let us think it through properly before rushing anything in which we are going to regret once we want to do more sophisticated time domain management, e.g. support for isolated clock real time. I'm worried, that without a clear plan about the overall picture, we end up with duct tape which is hard to distangle after the fact. There have been a few other things brought up versus time management in general, like the TSN folks utilizing grand clock masters which expose random time instead of proper TAI. Plus some requirements for exposing some sort of 'monotonic' clocks which are derived from external synchronization mechanisms, but should not affect the regular time keeping clocks. While different issues, these all fall into the category of separate time domains, so taking a step back to the drawing board is probably the best thing what we can do now. There are certainly a few things which can be looked at independently, e.g. the VDSO mechanics or general mechanisms to avoid plastering the whole kernel with these name space functions applying offsets left and right. I rather have dedicated core functionality which replaces/amends existing timer functions to become time namespace aware. I'll try to find some time in the next weeks to look deeper into that, but I can't promise anything before returning from LPC. Btw, LPC would be a great opportunity to discuss that. Are you and the other name space wizards there by any chance? Thanks, tglx
WARNING: multiple messages have this Message-ID (diff)
From: tglx@linutronix.de (Thomas Gleixner) Subject: [RFC 00/20] ns: Introduce Time Namespace Date: Mon, 29 Oct 2018 21:33:14 +0100 (CET) [thread overview] Message-ID: <alpine.DEB.2.21.1810292026040.5984@nanos.tec.linutronix.de> (raw) Message-ID: <20181029203314.muZ1W2A2bY2OI4JyEaJzGV6sPTNsKq0tbmeTc5KlIto@z> (raw) In-Reply-To: <20181021014121.GA23474@gmail.com> Andrei, On Sat, 20 Oct 2018, Andrei Vagin wrote: > When a container is migrated to another host, we have to restore its > monotonic and boottime clocks, but we still expect that the container > will continue using the host real-time clock. > > Before stating this series, I was thinking about this, I decided that > these cases can be solved independently. Probably, the full isolation of > the time sub-system will have much higher overhead than just offsets for > a few clocks. And the idea that isolation of the real-time clock should > be optional gives us another hint that offsets for monotonic and > boot-time clocks can be implemented independently. > > Eric and Tomas, what do you think about this? If you agree that these > two cases can be implemented separately, what should we do with this > series to make it ready to be merged? > > I know that we need to: > > * look at device drivers that report timestamps in CLOCK_MONOTONIC base. and CLOCK_BOOTTIME and that's quite a few. > * forbid changing offsets after creating timers There are more things to think about. What about interfaces which expose boot time or monotonic time in /proc? Aside of that (I finally came around to look at the series in more detail) I'm really unhappy about the unconditional overhead once the Time namespace config switch is enabled. This applies especially to the VDSO. We spent quite some time recently to squeeze a few cycles out of those functions and it would be a pity to pointlessly waste cycles for the !namespace case. I can see the urge for this, but please let us think it through properly before rushing anything in which we are going to regret once we want to do more sophisticated time domain management, e.g. support for isolated clock real time. I'm worried, that without a clear plan about the overall picture, we end up with duct tape which is hard to distangle after the fact. There have been a few other things brought up versus time management in general, like the TSN folks utilizing grand clock masters which expose random time instead of proper TAI. Plus some requirements for exposing some sort of 'monotonic' clocks which are derived from external synchronization mechanisms, but should not affect the regular time keeping clocks. While different issues, these all fall into the category of separate time domains, so taking a step back to the drawing board is probably the best thing what we can do now. There are certainly a few things which can be looked at independently, e.g. the VDSO mechanics or general mechanisms to avoid plastering the whole kernel with these name space functions applying offsets left and right. I rather have dedicated core functionality which replaces/amends existing timer functions to become time namespace aware. I'll try to find some time in the next weeks to look deeper into that, but I can't promise anything before returning from LPC. Btw, LPC would be a great opportunity to discuss that. Are you and the other name space wizards there by any chance? Thanks, tglx
next prev parent reply other threads:[~2018-10-29 20:33 UTC|newest] Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-09-19 20:50 [RFC 00/20] ns: Introduce Time Namespace dima 2018-09-19 20:50 ` Dmitry Safonov 2018-09-19 20:50 ` [RFC 16/20] selftest: Add Time Namespace test for supported clocks dima 2018-09-19 20:50 ` Dmitry Safonov 2018-09-24 21:36 ` shuah 2018-09-24 21:36 ` Shuah Khan 2018-09-19 20:50 ` [RFC 17/20] selftest/timens: Add test for timerfd dima 2018-09-19 20:50 ` Dmitry Safonov 2018-09-19 20:50 ` [RFC 18/20] selftest/timens: Add test for clock_nanosleep dima 2018-09-19 20:50 ` Dmitry Safonov 2018-09-19 20:50 ` [RFC 19/20] timens/selftest: Add procfs selftest dima 2018-09-19 20:50 ` Dmitry Safonov 2018-09-19 20:50 ` [RFC 20/20] timens/selftest: Add timer offsets test dima 2018-09-19 20:50 ` Dmitry Safonov 2018-09-21 12:27 ` [RFC 00/20] ns: Introduce Time Namespace ebiederm 2018-09-21 12:27 ` Eric W. Biederman 2018-09-24 20:51 ` avagin 2018-09-24 20:51 ` Andrey Vagin 2018-09-24 22:02 ` ebiederm 2018-09-24 22:02 ` Eric W. Biederman 2018-09-25 1:42 ` avagin 2018-09-25 1:42 ` Andrey Vagin 2018-09-26 17:36 ` ebiederm 2018-09-26 17:36 ` Eric W. Biederman 2018-09-26 17:59 ` 0x7f454c46 2018-09-26 17:59 ` Dmitry Safonov 2018-09-27 21:30 ` tglx 2018-09-27 21:30 ` Thomas Gleixner 2018-09-27 21:41 ` tglx 2018-09-27 21:41 ` Thomas Gleixner 2018-10-01 23:20 ` avagin 2018-10-01 23:20 ` Andrey Vagin 2018-10-02 6:15 ` tglx 2018-10-02 6:15 ` Thomas Gleixner 2018-10-02 21:05 ` 0x7f454c46 2018-10-02 21:05 ` Dmitry Safonov 2018-10-02 21:26 ` tglx 2018-10-02 21:26 ` Thomas Gleixner 2018-09-28 17:03 ` ebiederm 2018-09-28 17:03 ` Eric W. Biederman 2018-09-28 19:32 ` tglx 2018-09-28 19:32 ` Thomas Gleixner 2018-10-01 9:05 ` ebiederm 2018-10-01 9:05 ` Eric W. Biederman 2018-10-01 9:15 ` Setting monotonic time? ebiederm 2018-10-01 9:15 ` Eric W. Biederman 2018-10-01 18:52 ` tglx 2018-10-01 18:52 ` Thomas Gleixner 2018-10-02 20:00 ` arnd 2018-10-02 20:00 ` Arnd Bergmann 2018-10-02 20:06 ` tglx 2018-10-02 20:06 ` Thomas Gleixner 2018-10-03 4:50 ` ebiederm 2018-10-03 4:50 ` Eric W. Biederman 2018-10-03 5:25 ` tglx 2018-10-03 5:25 ` Thomas Gleixner 2018-10-03 6:14 ` ebiederm 2018-10-03 6:14 ` Eric W. Biederman 2018-10-03 7:02 ` arnd 2018-10-03 7:02 ` Arnd Bergmann 2018-10-03 6:14 ` tglx 2018-10-03 6:14 ` Thomas Gleixner 2018-10-01 20:51 ` avagin 2018-10-01 20:51 ` Andrey Vagin 2018-10-02 6:16 ` tglx 2018-10-02 6:16 ` Thomas Gleixner 2018-10-21 1:41 ` [RFC 00/20] ns: Introduce Time Namespace avagin 2018-10-21 1:41 ` Andrei Vagin 2018-10-21 3:54 ` avagin 2018-10-21 3:54 ` Andrei Vagin 2018-10-29 20:33 ` tglx [this message] 2018-10-29 20:33 ` Thomas Gleixner 2018-10-29 21:21 ` ebiederm 2018-10-29 21:21 ` Eric W. Biederman 2018-10-29 21:36 ` tglx 2018-10-29 21:36 ` Thomas Gleixner 2018-10-31 16:26 ` avagin 2018-10-31 16:26 ` Andrei Vagin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=alpine.DEB.2.21.1810292026040.5984@nanos.tec.linutronix.de \ --to=linux-kselftest@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).