From: tglx at linutronix.de (Thomas Gleixner) Subject: [RFC 00/20] ns: Introduce Time Namespace Date: Thu, 27 Sep 2018 23:30:09 +0200 (CEST) [thread overview] Message-ID: <alpine.DEB.2.21.1809272247270.8118@nanos.tec.linutronix.de> (raw) In-Reply-To: <87zhw4rwiq.fsf@xmission.com> On Wed, 26 Sep 2018, Eric W. Biederman wrote: > Reading the code the calling sequence there is: > tick_sched_do_timer > tick_do_update_jiffies64 > update_wall_time > timekeeping_advance > timekeepging_update > > If I read that properly under the right nohz circumstances that update > can be delayed indefinitely. > > So I think we could prototype a time namespace that was per > timekeeping_update and just had update_wall_time iterate through > all of the time namespaces. Please don't go there. timekeeping_update() is already heavy and walking through a gazillion of namespaces will just make it horrible, > I don't think the naive version would scale to very many time > namespaces. :) > At the same time using the techniques from the nohz work and a little > smarts I expect we could get the code to scale. You'd need to invoke the update when the namespace is switched in and hasn't been updated since the last tick happened. That might be doable, but you also need to take the wraparound constraints of the underlying clocksources into account, which again can cause walking all name spaces when they are all idle long enough. >From there it becomes hairy, because it's not only timekeeping, i.e. reading time, this is also affecting all timers which are armed from a namespace. That gets really ugly because when you do settimeofday() or adjtimex() for a particular namespace, then you have to search for all armed timers of that namespace and adjust them. The original posix timer code had the same issue because it mapped the clock realtime timers to the timer wheel so any setting of the clock caused a full walk of all armed timers, disarming, adjusting and requeing them. That's horrible not only performance wise, it's also a locking nightmare of all sorts. Add time skew via NTP/PTP into the picture and you might have to adjust timers as well, because you need to guarantee that they are not expiring early. I haven't looked through Dimitry's patches yet, but I don't see how this can work at all without introducing subtle issues all over the place. 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: Thu, 27 Sep 2018 23:30:09 +0200 (CEST) [thread overview] Message-ID: <alpine.DEB.2.21.1809272247270.8118@nanos.tec.linutronix.de> (raw) Message-ID: <20180927213009.AbrvKX3VTHSF66Roqq9N64QIbj6UsmtuBa0W9900gH0@z> (raw) In-Reply-To: <87zhw4rwiq.fsf@xmission.com> On Wed, 26 Sep 2018, Eric W. Biederman wrote: > Reading the code the calling sequence there is: > tick_sched_do_timer > tick_do_update_jiffies64 > update_wall_time > timekeeping_advance > timekeepging_update > > If I read that properly under the right nohz circumstances that update > can be delayed indefinitely. > > So I think we could prototype a time namespace that was per > timekeeping_update and just had update_wall_time iterate through > all of the time namespaces. Please don't go there. timekeeping_update() is already heavy and walking through a gazillion of namespaces will just make it horrible, > I don't think the naive version would scale to very many time > namespaces. :) > At the same time using the techniques from the nohz work and a little > smarts I expect we could get the code to scale. You'd need to invoke the update when the namespace is switched in and hasn't been updated since the last tick happened. That might be doable, but you also need to take the wraparound constraints of the underlying clocksources into account, which again can cause walking all name spaces when they are all idle long enough. >From there it becomes hairy, because it's not only timekeeping, i.e. reading time, this is also affecting all timers which are armed from a namespace. That gets really ugly because when you do settimeofday() or adjtimex() for a particular namespace, then you have to search for all armed timers of that namespace and adjust them. The original posix timer code had the same issue because it mapped the clock realtime timers to the timer wheel so any setting of the clock caused a full walk of all armed timers, disarming, adjusting and requeing them. That's horrible not only performance wise, it's also a locking nightmare of all sorts. Add time skew via NTP/PTP into the picture and you might have to adjust timers as well, because you need to guarantee that they are not expiring early. I haven't looked through Dimitry's patches yet, but I don't see how this can work at all without introducing subtle issues all over the place. Thanks, tglx
next prev parent reply other threads:[~2018-09-27 21:30 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 [this message] 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 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.1809272247270.8118@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).