From: tglx at linutronix.de (Thomas Gleixner) Subject: [RFC 00/20] ns: Introduce Time Namespace Date: Tue, 2 Oct 2018 23:26:30 +0200 (CEST) [thread overview] Message-ID: <alpine.DEB.2.21.1810022310360.1435@nanos.tec.linutronix.de> (raw) In-Reply-To: <CAJwJo6a+WWpAxVAUuYt8TrCF+1a=BdoFQjU9vto0iiUN5vygsA@mail.gmail.com> Dmitry, On Tue, 2 Oct 2018, Dmitry Safonov wrote: > On Tue, 2 Oct 2018 at 07:15, Thomas Gleixner <tglx at linutronix.de> wrote: > > I explained that in detail in this thread, but it's not about the initial > > setting of clock mono/boot before any timers have been armed. > > > > It's about setting the offset or clock realtime (via settimeofday) when > > timers are already armed. Also having a entirely different time domain, > > e.g. separate NTP adjustments, makes that necessary. > > It looks like, there is a bit of misunderstanding each other: > Andrei was talking about the current RFC version, where we haven't > introduced offsets for clock realtime. While Thomas IIUC, is looking > how-to expand time namespace over realtime. > > As CLOCK_REALTIME virtualization raises so many complex questions > like a different length of the second or list of realtime timers in ns we > haven't added any realization for it. > > It seems like an initial introduction for timens can be expanded after to cover > realtime clocks too. While it may seem incomplete, it solves issues for > restoring/migration of real-world applications like nodejs, Oracle DB server > which fails after being restored if there is a leap in monotonic time. Well, yes. But you really have to think about the full picture. Just adding part of the overall solution right now, just because it can be glued into the code easily, is not the best approach IMO as it might result in substantial rework of the whole thing sooner than later. I really don't want to end up with something which is not extensible and has to be supported forever. Just for the record, the current approach with name space offsets for monotonic is also prone to malfunction vs. timers, unless you can prevent changing the offset _after_ the namespace has been set up and timers have been armed. I admit, that I did not look close enough to verify that. > While solving the mentioned issues, it doesn't bring overhead. > (well, Andy noted that cmp for zero-offsets on vdso can be optimized too, > which will be done in v1). > > Thomas, thanks much for your input - now we know that we'll need to > introduce list for timers in namespace when we'll add realtime clocks. > Do you believe that CLOCK_MONOTONIC_SYNC would be an easier > concept than offsets per-namespace? Haven't thought it through. This was just an idea in reaction to Eric's question whether setting clock monotonic might be feasible. But yes, it might be worth to think about it. I think you should really define the long term requirements for time namespaces and perhaps set some limitations in functionality upfront. 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: Tue, 2 Oct 2018 23:26:30 +0200 (CEST) [thread overview] Message-ID: <alpine.DEB.2.21.1810022310360.1435@nanos.tec.linutronix.de> (raw) Message-ID: <20181002212630.TUDhKgM21gVJYYnOVuL-umDZEnSorzR7UaZhKcOolBE@z> (raw) In-Reply-To: <CAJwJo6a+WWpAxVAUuYt8TrCF+1a=BdoFQjU9vto0iiUN5vygsA@mail.gmail.com> Dmitry, On Tue, 2 Oct 2018, Dmitry Safonov wrote: > On Tue, 2 Oct 2018@07:15, Thomas Gleixner <tglx@linutronix.de> wrote: > > I explained that in detail in this thread, but it's not about the initial > > setting of clock mono/boot before any timers have been armed. > > > > It's about setting the offset or clock realtime (via settimeofday) when > > timers are already armed. Also having a entirely different time domain, > > e.g. separate NTP adjustments, makes that necessary. > > It looks like, there is a bit of misunderstanding each other: > Andrei was talking about the current RFC version, where we haven't > introduced offsets for clock realtime. While Thomas IIUC, is looking > how-to expand time namespace over realtime. > > As CLOCK_REALTIME virtualization raises so many complex questions > like a different length of the second or list of realtime timers in ns we > haven't added any realization for it. > > It seems like an initial introduction for timens can be expanded after to cover > realtime clocks too. While it may seem incomplete, it solves issues for > restoring/migration of real-world applications like nodejs, Oracle DB server > which fails after being restored if there is a leap in monotonic time. Well, yes. But you really have to think about the full picture. Just adding part of the overall solution right now, just because it can be glued into the code easily, is not the best approach IMO as it might result in substantial rework of the whole thing sooner than later. I really don't want to end up with something which is not extensible and has to be supported forever. Just for the record, the current approach with name space offsets for monotonic is also prone to malfunction vs. timers, unless you can prevent changing the offset _after_ the namespace has been set up and timers have been armed. I admit, that I did not look close enough to verify that. > While solving the mentioned issues, it doesn't bring overhead. > (well, Andy noted that cmp for zero-offsets on vdso can be optimized too, > which will be done in v1). > > Thomas, thanks much for your input - now we know that we'll need to > introduce list for timers in namespace when we'll add realtime clocks. > Do you believe that CLOCK_MONOTONIC_SYNC would be an easier > concept than offsets per-namespace? Haven't thought it through. This was just an idea in reaction to Eric's question whether setting clock monotonic might be feasible. But yes, it might be worth to think about it. I think you should really define the long term requirements for time namespaces and perhaps set some limitations in functionality upfront. Thanks, tglx
next prev parent reply other threads:[~2018-10-02 21:26 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 [this message] 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 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.1810022310360.1435@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).