Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp410715imm; Mon, 1 Oct 2018 11:54:54 -0700 (PDT) X-Google-Smtp-Source: ACcGV60IQW+Oc+TKZmkAvsIjNJWcyRfVYYOMk/byXg3tfVYzXBULL5ugfzgB+Lz0Dz95rTT9HXos X-Received: by 2002:a62:384c:: with SMTP id f73-v6mr12936428pfa.242.1538420094546; Mon, 01 Oct 2018 11:54:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538420094; cv=none; d=google.com; s=arc-20160816; b=LtExPDw7dLU3kwoZUSn1aybXlSuEH9jbpXS617NyRSP2pwzuDrmC4nDvPeApGhYV8C V2Uhz8vqYxNDrptMQIEfl9Zi2M42sWUCk1YUq1CdvCae6jkMQmhVYVsm3eG71UoYD/rh ORRa+/6wgRbyGxrJGm0HiUqoRYlHVa8KleTkWmdeHqJsiBL0NBvGDPYyTPVwbQ7CdVbL IZRKLcrFZ9ZuF/ncsSFRAsMwunh0d+0UXEp86Do7nGXvz7FfrhmvQe1mp1a6TiQEjVXK VaSBE1HLI+061MWBjwmtewa+qbOmSGfkXGHofy1dy+QRa0HPo0v+kLnSrPxAz4lz1NDH Se8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=+oncjeo2ISge27ZGeh0V3fMLHp2VtmYKrm2LjksXAuM=; b=aAmHDhkGQm/tgxyb+6A/eYsSHpCVZMEGmKOATPj4eii4YYHS0g1IuqlA8guycxAEia 1tKVzb1K2X3OlC5Avrs3n0H3WJMK4YDcVHYlanfmRSmU+yxw9JjMjE7UVKrdte+PPepx P783VMza85d4RqO+mQvft32gYTc4pDo8hTGB4bz48zChEg5P09+oPSvlotDMSKvUVLrl PFv66RAaZmBYWZFhECRzdnGJUiJmd8LMRQwioJ0M5wfYa5he/Jx++hU5rNQD3FjE6ux9 wVVIrszjHd6PTQILK2AMfasAzOZAv+CpMV1yxTcQN76sCcbpYHoy9RODCpzBdDuZ25q5 E9pQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i7-v6si11493695pgs.174.2018.10.01.11.54.39; Mon, 01 Oct 2018 11:54:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726354AbeJBBc0 (ORCPT + 99 others); Mon, 1 Oct 2018 21:32:26 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:58349 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725975AbeJBBcZ (ORCPT ); Mon, 1 Oct 2018 21:32:25 -0400 Received: from p5492e4c1.dip0.t-ipconnect.de ([84.146.228.193] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1g73JB-0002bV-Sa; Mon, 01 Oct 2018 20:52:42 +0200 Date: Mon, 1 Oct 2018 20:52:41 +0200 (CEST) From: Thomas Gleixner To: "Eric W. Biederman" cc: Andrey Vagin , Dmitry Safonov , "linux-kernel@vger.kernel.org" , Dmitry Safonov <0x7f454c46@gmail.com>, Adrian Reber , Andy Lutomirski , Christian Brauner , Cyrill Gorcunov , "H. Peter Anvin" , Ingo Molnar , Jeff Dike , Oleg Nesterov , Pavel Emelianov , Shuah Khan , "containers@lists.linux-foundation.org" , "criu@openvz.org" , "linux-api@vger.kernel.org" , "x86@kernel.org" , Alexey Dobriyan , "linux-kselftest@vger.kernel.org" Subject: Re: Setting monotonic time? In-Reply-To: <877ej2xc23.fsf_-_@xmission.com> Message-ID: References: <20180919205037.9574-1-dima@arista.com> <874lej6nny.fsf@xmission.com> <20180924205119.GA14833@outlook.office365.com> <874leezh8n.fsf@xmission.com> <20180925014150.GA6302@outlook.office365.com> <87zhw4rwiq.fsf@xmission.com> <87mus1ftb9.fsf@xmission.com> <877ej2xc23.fsf_-_@xmission.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 1 Oct 2018, Eric W. Biederman wrote: > 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. It's used very early on in the kernel, so that would be a major surprise for many things including user space which has expectations on clock monotonic. It would be reasonably easy to add CLOCK_MONONOTIC_SYNC which can be set in the way you described and then in name spaces make it possible to magically map CLOCK_MONOTONIC to CLOCK_MONOTONIC_SYNC. It still wouldn't allow to have different NTP/PTP time domains, but might be a good start to address the main migration headaches. Thanks, tglx