Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1731099imm; Tue, 2 Oct 2018 13:02:20 -0700 (PDT) X-Google-Smtp-Source: ACcGV61E+WNP5RT42JMo9evHos0Wa9Ajakc+a0DB7PCOPnYZhUfxp2sAXC8xBnISuZf6foVGvcIf X-Received: by 2002:a63:450b:: with SMTP id s11-v6mr2580252pga.301.1538510540321; Tue, 02 Oct 2018 13:02:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538510540; cv=none; d=google.com; s=arc-20160816; b=rWH8qQ60N7qFnI5I1d+da1tEe6uUoDY6NzA9wZmp05+VZpocAiiCWCO/kwml67SZfX aSTOp5ftMwxs+CGKZQOXpa9Dyb7fR3N4CB+C2+ezeY617jeO1gd7V2S9JK6f6+RShkN6 yFxRW/YFf2bvstDsp6MVMmWziHU3e6teDIgdabTCuu13MQHM4BMnN4RKzWlPK+6K48IV C29VUOVYkh1sexxXQbf2HoBJlPj1jTWWzpU5jKcGj6VewM1KSnX5yFDpbW/ulF/9w5wp ejTqszJKBWNmaw5d8TpRCwUDzrYin/Tdcnev9jrcYv7PYzLH7BBv7gb/q0epivBcwHa+ zWlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=tbAgm1sdy6c14middsYvcrFNeOfV2v5PzjYHIWArWE0=; b=wd7qpNgC4rvSvMWTlMQEd6WZ/DJiyEe4rIEMbXwi835b+fP9+JmZAO2I13h8qWkwAf zh3QDSo7mGnhUB8VNhT+7/URpiZ+u7ydd/xNOcGhup42hfrxN0CmN+B0l5su0z0y3nrt JBNdA30xBXSecvVZ+7aXs+Y2uJrl5tz7jampNLUrm7U/Af1IPL2+SZZPhvFCVn5RVLqd P4U2T/i6M0kR+lhWhajqklLerFj/x2x9INTUiZqMc5r6RIf4upTmihRtUC6OWoxzMUU0 tI0cjLkLCqAAwPKr3jAyRgAGM5/BHziU4UDU/kk6XtMeQjlC9AXPKHQcDJoO34sla7M5 bFsA== 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 j6-v6si7773341plk.145.2018.10.02.13.02.03; Tue, 02 Oct 2018 13:02:20 -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 S1727417AbeJCCqR (ORCPT + 99 others); Tue, 2 Oct 2018 22:46:17 -0400 Received: from mail-qk1-f181.google.com ([209.85.222.181]:44204 "EHLO mail-qk1-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726563AbeJCCqR (ORCPT ); Tue, 2 Oct 2018 22:46:17 -0400 Received: by mail-qk1-f181.google.com with SMTP id y8-v6so1978090qka.11; Tue, 02 Oct 2018 13:01:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tbAgm1sdy6c14middsYvcrFNeOfV2v5PzjYHIWArWE0=; b=Gql9AL68pTfsuw7tpkFNbY9n4bVQL9CcyRA2oe9Kp5RHgJGrGWTQMsWIXLketqZS+K MyKC9BL8Dvf3wbUCRnoN1PL/sJ5jYddOjNtbeWF2K0N7ld71Hiy2sUHvtoBDCISof2W9 j8LGzK3ZK9LWvtnjlIhCFbALtUmIyqdXe4I0x4TV0MWI6I7IaALjcmtzGoeiBMaGYjd6 m7BpMyDTobHoliDsDwwuChAJcDNUuPPV3qhDGGFvluoj/pxWEiWHkmcrqFra0xHruGOb dPc1SMEl8QZJQLERhaanBuwc1jEwIErcu2QVBUCUAw0qn2HNEH+6GoYbSYpdlhXL0pob dRRw== X-Gm-Message-State: ABuFfogySmqzSu3T/i/Vbu1v/K5rGBncnkbycNQFmflxke3TUb/H7ANH dIcaYg3m43gL0iixmCQP1Pgs4TSamdoK4AavpDc= X-Received: by 2002:a37:e21a:: with SMTP id g26-v6mr2969025qki.330.1538510475018; Tue, 02 Oct 2018 13:01:15 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Arnd Bergmann Date: Tue, 2 Oct 2018 22:00:57 +0200 Message-ID: Subject: Re: Setting monotonic time? To: Thomas Gleixner Cc: "Eric W . Biederman" , avagin@virtuozzo.com, dima@arista.com, Linux Kernel Mailing List , 0x7f454c46@gmail.com, adrian@lisas.de, Andy Lutomirski , Christian Brauner , gorcunov@openvz.org, "H. Peter Anvin" , Ingo Molnar , Jeff Dike , Oleg Nesterov , xemul@virtuozzo.com, Shuah Khan , containers@lists.linux-foundation.org, criu@openvz.org, Linux API , "the arch/x86 maintainers" , Alexey Dobriyan , linux-kselftest@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 1, 2018 at 8:53 PM Thomas Gleixner wrote: > > 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. If we make CLOCK_MONOTONIC settable this way in a namespace, do you think that should include device drivers that report timestamps in CLOCK_MONOTONIC base, or only the timekeeping clock and timer interfaces? Examples for drivers that can report timestamps are input, sound, v4l, and drm. I think most of these can report stamps in either monotonic or realtime base, while socket timestamps notably are always in realtime. We can probably get away with not setting the timebase for those device drivers as long as the checkpoint/restart and migration features are not expected to restore the state of an open character device in that way. I don't know if that is a reasonable assumption to make for the examples I listed. Arnd