From: ebiederm@xmission.com (Eric W. Biederman)
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrey Vagin <avagin@virtuozzo.com>,
Dmitry Safonov <dima@arista.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Dmitry Safonov <0x7f454c46@gmail.com>,
Adrian Reber <adrian@lisas.de>, Andy Lutomirski <luto@kernel.org>,
Christian Brauner <christian.brauner@ubuntu.com>,
Cyrill Gorcunov <gorcunov@openvz.org>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
Jeff Dike <jdike@addtoit.com>, Oleg Nesterov <oleg@redhat.com>,
Pavel Emelianov <xemul@virtuozzo.com>,
Shuah Khan <shuah@kernel.org>,
"containers@lists.linux-foundation.org"
<containers@lists.linux-foundation.org>,
"criu@openvz.org" <criu@openvz.org>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
Alexey
Subject: Setting monotonic time?
Date: Mon, 01 Oct 2018 11:15:32 +0200 [thread overview]
Message-ID: <877ej2xc23.fsf_-_@xmission.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1809282023350.1432@nanos.tec.linutronix.de> (Thomas Gleixner's message of "Fri, 28 Sep 2018 21:32:15 +0200 (CEST)")
In the context of process migration there is a simpler subproblem that I
think it is worth exploring if we can do something about.
For a cluster of machines all running with synchronized
clocks. CLOCK_REALTIME matches. CLOCK_MONOTNIC does not match between
machines. Not having a matching CLOCK_MONOTONIC prevents successful
process migration between nodes in that cluster.
Would it be possible to allow setting CLOCK_MONOTONIC at the very
beginning of time? So that all of the nodes in a cluster can be in
sync?
No change in skew just in offset for CLOCK_MONOTONIC.
There are also dragons involved in coordinating things so that
CLOCK_MONOTONIC gets set before CLOCK_MONOTONIC gets used. So I don't
know if allowing CLOCK_MONOTONIC to be set would be practical but it
seems work exploring all on it's own.
Dmitry would setting CLOCK_MONOTONIC exactly once at boot time solve
your problem that is you are looking at a time namespace to solve?
Eric
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm at xmission.com (Eric W. Biederman)
Subject: Setting monotonic time?
Date: Mon, 01 Oct 2018 11:15:32 +0200 [thread overview]
Message-ID: <877ej2xc23.fsf_-_@xmission.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1809282023350.1432@nanos.tec.linutronix.de> (Thomas Gleixner's message of "Fri, 28 Sep 2018 21:32:15 +0200 (CEST)")
In the context of process migration there is a simpler subproblem that I
think it is worth exploring if we can do something about.
For a cluster of machines all running with synchronized
clocks. CLOCK_REALTIME matches. CLOCK_MONOTNIC does not match between
machines. Not having a matching CLOCK_MONOTONIC prevents successful
process migration between nodes in that cluster.
Would it be possible to allow setting CLOCK_MONOTONIC at the very
beginning of time? So that all of the nodes in a cluster can be in
sync?
No change in skew just in offset for CLOCK_MONOTONIC.
There are also dragons involved in coordinating things so that
CLOCK_MONOTONIC gets set before CLOCK_MONOTONIC gets used. So I don't
know if allowing CLOCK_MONOTONIC to be set would be practical but it
seems work exploring all on it's own.
Dmitry would setting CLOCK_MONOTONIC exactly once at boot time solve
your problem that is you are looking at a time namespace to solve?
Eric
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
Subject: Setting monotonic time?
Date: Mon, 01 Oct 2018 11:15:32 +0200 [thread overview]
Message-ID: <877ej2xc23.fsf_-_@xmission.com> (raw)
Message-ID: <20181001091532.RN1YfcbsCOfIIKKf5KyWYmWpgirbozlmrDY87Tw8MS8@z> (raw)
In-Reply-To: <alpine.DEB.2.21.1809282023350.1432@nanos.tec.linutronix.de> (Thomas Gleixner's message of "Fri, 28 Sep 2018 21:32:15 +0200 (CEST)")
In the context of process migration there is a simpler subproblem that I
think it is worth exploring if we can do something about.
For a cluster of machines all running with synchronized
clocks. CLOCK_REALTIME matches. CLOCK_MONOTNIC does not match between
machines. Not having a matching CLOCK_MONOTONIC prevents successful
process migration between nodes in that cluster.
Would it be possible to allow setting CLOCK_MONOTONIC at the very
beginning of time? So that all of the nodes in a cluster can be in
sync?
No change in skew just in offset for CLOCK_MONOTONIC.
There are also dragons involved in coordinating things so that
CLOCK_MONOTONIC gets set before CLOCK_MONOTONIC gets used. So I don't
know if allowing CLOCK_MONOTONIC to be set would be practical but it
seems work exploring all on it's own.
Dmitry would setting CLOCK_MONOTONIC exactly once at boot time solve
your problem that is you are looking at a time namespace to solve?
Eric
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrey Vagin <avagin@virtuozzo.com>,
Dmitry Safonov <dima@arista.com>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Dmitry Safonov <0x7f454c46@gmail.com>,
Adrian Reber <adrian@lisas.de>, Andy Lutomirski <luto@kernel.org>,
Christian Brauner <christian.brauner@ubuntu.com>,
Cyrill Gorcunov <gorcunov@openvz.org>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
Jeff Dike <jdike@addtoit.com>, Oleg Nesterov <oleg@redhat.com>,
Pavel Emelianov <xemul@virtuozzo.com>,
Shuah Khan <shuah@kernel.org>,
"containers\@lists.linux-foundation.org"
<containers@lists.linux-foundation.org>,
"criu\@openvz.org" <criu@openvz.org>,
"linux-api\@vger.kernel.org" <linux-api@vger.kernel.org>,
"x86\@kernel.org" <x86@kernel.org>,
Alexey Dobriyan <adobriyan@gmail.com>,
"linux-kselftest\@vger.kernel.org"
<linux-kselftest@vger.kernel.org>
Subject: Setting monotonic time?
Date: Mon, 01 Oct 2018 11:15:32 +0200 [thread overview]
Message-ID: <877ej2xc23.fsf_-_@xmission.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1809282023350.1432@nanos.tec.linutronix.de> (Thomas Gleixner's message of "Fri, 28 Sep 2018 21:32:15 +0200 (CEST)")
In the context of process migration there is a simpler subproblem that I
think it is worth exploring if we can do something about.
For a cluster of machines all running with synchronized
clocks. CLOCK_REALTIME matches. CLOCK_MONOTNIC does not match between
machines. Not having a matching CLOCK_MONOTONIC prevents successful
process migration between nodes in that cluster.
Would it be possible to allow setting CLOCK_MONOTONIC at the very
beginning of time? So that all of the nodes in a cluster can be in
sync?
No change in skew just in offset for CLOCK_MONOTONIC.
There are also dragons involved in coordinating things so that
CLOCK_MONOTONIC gets set before CLOCK_MONOTONIC gets used. So I don't
know if allowing CLOCK_MONOTONIC to be set would be practical but it
seems work exploring all on it's own.
Dmitry would setting CLOCK_MONOTONIC exactly once at boot time solve
your problem that is you are looking at a time namespace to solve?
Eric
next prev parent reply other threads:[~2018-10-01 9:15 UTC|newest]
Thread overview: 164+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-19 20:50 [RFC 00/20] ns: Introduce Time Namespace Dmitry Safonov
2018-09-19 20:50 ` Dmitry Safonov
2018-09-19 20:50 ` Dmitry Safonov
2018-09-19 20:50 ` dima
2018-09-19 20:50 ` [RFC 01/20] " Dmitry Safonov
2018-09-28 18:20 ` Laurent Vivier
2018-09-19 20:50 ` [RFC 02/20] timens: Add timens_offsets Dmitry Safonov
2018-09-20 18:45 ` Cyrill Gorcunov
2018-09-20 22:14 ` Cyrill Gorcunov
2018-09-19 20:50 ` [RFC 03/20] timens: Introduce CLOCK_MONOTONIC offsets Dmitry Safonov
2018-09-19 20:50 ` [RFC 04/20] timens: Introduce CLOCK_BOOTTIME offset Dmitry Safonov
2018-09-30 3:18 ` [LKP] [timens] 3cc8de9dcb: RIP:posix_get_boottime kernel test robot
2018-09-30 3:18 ` kernel test robot
2018-09-30 3:18 ` kernel test robot
2018-09-19 20:50 ` [RFC 05/20] timerfd/timens: Take into account ns clock offsets Dmitry Safonov
2018-09-19 20:50 ` [RFC 06/20] kernel: Take into account timens clock offsets in clock_nanosleep Dmitry Safonov
2018-09-19 20:50 ` [RFC 07/20] timens: Shift /proc/uptime Dmitry Safonov
2018-09-19 20:50 ` [RFC 08/20] x86/vdso: Restrict splitting vvar vma Dmitry Safonov
2018-09-19 20:50 ` [RFC 09/20] x86/vdso/timens: Add offsets page in vvar Dmitry Safonov
2018-09-19 20:50 ` [RFC 10/20] x86/vdso: Use set_normalized_timespec() to avoid 32 bit overflow Dmitry Safonov
2018-09-19 20:50 ` [RFC 11/20] x86/vdso: Purge timens page on setns()/unshare()/clone() Dmitry Safonov
2018-09-19 20:50 ` [RFC 12/20] x86/vdso: Look for vvar vma to purge timens page Dmitry Safonov
2018-09-19 20:50 ` [RFC 13/20] posix-timers/timens: Take into account clock offsets Dmitry Safonov
2018-09-30 3:11 ` [LKP] [posix] 25217c6e39: BUG:KASAN:null-ptr-deref_in_c kernel test robot
2018-09-30 3:11 ` kernel test robot
2018-09-30 3:11 ` kernel test robot
2018-09-19 20:50 ` [RFC 14/20] timens: Add align for timens_offsets Dmitry Safonov
2018-09-19 20:50 ` [RFC 15/20] timens: Optimize zero-offsets Dmitry Safonov
2018-09-19 20:50 ` [RFC 16/20] selftest: Add Time Namespace test for supported clocks Dmitry Safonov
2018-09-19 20:50 ` Dmitry Safonov
2018-09-19 20:50 ` dima
2018-09-24 21:36 ` Shuah Khan
2018-09-24 21:36 ` Shuah Khan
2018-09-24 21:36 ` shuah
2018-09-19 20:50 ` [RFC 17/20] selftest/timens: Add test for timerfd Dmitry Safonov
2018-09-19 20:50 ` Dmitry Safonov
2018-09-19 20:50 ` dima
2018-09-19 20:50 ` [RFC 18/20] selftest/timens: Add test for clock_nanosleep Dmitry Safonov
2018-09-19 20:50 ` Dmitry Safonov
2018-09-19 20:50 ` dima
2018-09-19 20:50 ` [RFC 19/20] timens/selftest: Add procfs selftest Dmitry Safonov
2018-09-19 20:50 ` Dmitry Safonov
2018-09-19 20:50 ` dima
2018-09-19 20:50 ` [RFC 20/20] timens/selftest: Add timer offsets test Dmitry Safonov
2018-09-19 20:50 ` Dmitry Safonov
2018-09-19 20:50 ` dima
2018-09-21 12:27 ` [RFC 00/20] ns: Introduce Time Namespace Eric W. Biederman
2018-09-21 12:27 ` Eric W. Biederman
2018-09-21 12:27 ` ebiederm
2018-09-24 20:51 ` Andrey Vagin
2018-09-24 20:51 ` Andrey Vagin
2018-09-24 20:51 ` Andrey Vagin
2018-09-24 20:51 ` avagin
2018-09-24 22:02 ` Eric W. Biederman
2018-09-24 22:02 ` Eric W. Biederman
2018-09-24 22:02 ` Eric W. Biederman
2018-09-24 22:02 ` ebiederm
2018-09-25 1:42 ` Andrey Vagin
2018-09-25 1:42 ` Andrey Vagin
2018-09-25 1:42 ` Andrey Vagin
2018-09-25 1:42 ` avagin
2018-09-26 17:36 ` Eric W. Biederman
2018-09-26 17:36 ` Eric W. Biederman
2018-09-26 17:36 ` Eric W. Biederman
2018-09-26 17:36 ` ebiederm
2018-09-26 17:59 ` Dmitry Safonov
2018-09-26 17:59 ` Dmitry Safonov
2018-09-26 17:59 ` Dmitry Safonov
2018-09-26 17:59 ` 0x7f454c46
2018-09-27 21:30 ` Thomas Gleixner
2018-09-27 21:30 ` Thomas Gleixner
2018-09-27 21:30 ` Thomas Gleixner
2018-09-27 21:30 ` tglx
2018-09-27 21:41 ` Thomas Gleixner
2018-09-27 21:41 ` Thomas Gleixner
2018-09-27 21:41 ` Thomas Gleixner
2018-09-27 21:41 ` tglx
2018-10-01 23:20 ` Andrey Vagin
2018-10-01 23:20 ` Andrey Vagin
2018-10-01 23:20 ` Andrey Vagin
2018-10-01 23:20 ` avagin
2018-10-02 6:15 ` Thomas Gleixner
2018-10-02 6:15 ` Thomas Gleixner
2018-10-02 6:15 ` Thomas Gleixner
2018-10-02 6:15 ` tglx
2018-10-02 21:05 ` Dmitry Safonov
2018-10-02 21:05 ` Dmitry Safonov
2018-10-02 21:05 ` 0x7f454c46
2018-10-02 21:26 ` Thomas Gleixner
2018-10-02 21:26 ` Thomas Gleixner
2018-10-02 21:26 ` tglx
2018-09-28 17:03 ` Eric W. Biederman
2018-09-28 17:03 ` Eric W. Biederman
2018-09-28 17:03 ` Eric W. Biederman
2018-09-28 17:03 ` ebiederm
2018-09-28 19:32 ` Thomas Gleixner
2018-09-28 19:32 ` Thomas Gleixner
2018-09-28 19:32 ` Thomas Gleixner
2018-09-28 19:32 ` tglx
2018-10-01 9:05 ` Eric W. Biederman
2018-10-01 9:05 ` Eric W. Biederman
2018-10-01 9:05 ` Eric W. Biederman
2018-10-01 9:05 ` ebiederm
2018-10-01 9:15 ` Eric W. Biederman [this message]
2018-10-01 9:15 ` Setting monotonic time? Eric W. Biederman
2018-10-01 9:15 ` Eric W. Biederman
2018-10-01 9:15 ` ebiederm
2018-10-01 18:52 ` Thomas Gleixner
2018-10-01 18:52 ` Thomas Gleixner
2018-10-01 18:52 ` Thomas Gleixner
2018-10-01 18:52 ` tglx
2018-10-02 20:00 ` Arnd Bergmann
2018-10-02 20:00 ` Arnd Bergmann
2018-10-02 20:00 ` arnd
2018-10-02 20:06 ` Thomas Gleixner
2018-10-02 20:06 ` Thomas Gleixner
2018-10-02 20:06 ` tglx
2018-10-03 4:50 ` Eric W. Biederman
2018-10-03 4:50 ` Eric W. Biederman
2018-10-03 4:50 ` ebiederm
2018-10-03 5:25 ` Thomas Gleixner
2018-10-03 5:25 ` Thomas Gleixner
2018-10-03 5:25 ` tglx
2018-10-03 6:14 ` Eric W. Biederman
2018-10-03 6:14 ` Eric W. Biederman
2018-10-03 6:14 ` ebiederm
2018-10-03 7:02 ` Arnd Bergmann
2018-10-03 7:02 ` Arnd Bergmann
2018-10-03 7:02 ` arnd
2018-10-03 6:14 ` Thomas Gleixner
2018-10-03 6:14 ` Thomas Gleixner
2018-10-03 6:14 ` tglx
2018-10-01 20:51 ` Andrey Vagin
2018-10-01 20:51 ` Andrey Vagin
2018-10-01 20:51 ` Andrey Vagin
2018-10-01 20:51 ` avagin
2018-10-02 6:16 ` Thomas Gleixner
2018-10-02 6:16 ` Thomas Gleixner
2018-10-02 6:16 ` Thomas Gleixner
2018-10-02 6:16 ` tglx
2018-10-21 1:41 ` [RFC 00/20] ns: Introduce Time Namespace Andrei Vagin
2018-10-21 1:41 ` Andrei Vagin
2018-10-21 1:41 ` Andrei Vagin
2018-10-21 1:41 ` avagin
2018-10-21 3:54 ` Andrei Vagin
2018-10-21 3:54 ` Andrei Vagin
2018-10-21 3:54 ` Andrei Vagin
2018-10-21 3:54 ` avagin
2018-10-29 20:33 ` Thomas Gleixner
2018-10-29 20:33 ` Thomas Gleixner
2018-10-29 20:33 ` Thomas Gleixner
2018-10-29 20:33 ` tglx
2018-10-29 21:21 ` Eric W. Biederman
2018-10-29 21:21 ` Eric W. Biederman
2018-10-29 21:21 ` Eric W. Biederman
2018-10-29 21:21 ` ebiederm
2018-10-29 21:36 ` Thomas Gleixner
2018-10-29 21:36 ` Thomas Gleixner
2018-10-29 21:36 ` Thomas Gleixner
2018-10-29 21:36 ` tglx
2018-10-31 16:26 ` Andrei Vagin
2018-10-31 16:26 ` Andrei Vagin
2018-10-31 16:26 ` Andrei Vagin
2018-10-31 16:26 ` avagin
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=877ej2xc23.fsf_-_@xmission.com \
--to=ebiederm@xmission.com \
--cc=0x7f454c46@gmail.com \
--cc=adrian@lisas.de \
--cc=avagin@virtuozzo.com \
--cc=christian.brauner@ubuntu.com \
--cc=containers@lists.linux-foundation.org \
--cc=criu@openvz.org \
--cc=dima@arista.com \
--cc=gorcunov@openvz.org \
--cc=hpa@zytor.com \
--cc=jdike@addtoit.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=shuah@kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xemul@virtuozzo.com \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.