From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrei Vagin Subject: Re: [RFC 00/20] ns: Introduce Time Namespace Date: Wed, 31 Oct 2018 09:26:53 -0700 Message-ID: <20181031162650.GB26067@gmail.com> 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> <20181021014121.GA23474@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Thomas Gleixner Cc: "Eric W. Biederman" , "linux-kselftest@vger.kernel.org" , Dmitry Safonov , "linux-api@vger.kernel.org" , Jeff Dike , "x86@kernel.org" , Dmitry Safonov <0x7f454c46@gmail.com>, "linux-kernel@vger.kernel.org" , Oleg Nesterov , "criu@openvz.org" , Ingo Molnar , Alexey Dobriyan , Andy Lutomirski , "H. Peter Anvin" , Cyrill Gorcunov , Christian Brauner , Pavel Emelianov , Shuah Khan , container List-Id: linux-api@vger.kernel.org On Mon, Oct 29, 2018 at 09:33:14PM +0100, Thomas Gleixner wrote: > Andrei, > > On Sat, 20 Oct 2018, Andrei Vagin wrote: > > When a container is migrated to another host, we have to restore its > > monotonic and boottime clocks, but we still expect that the container > > will continue using the host real-time clock. > > > > Before stating this series, I was thinking about this, I decided that > > these cases can be solved independently. Probably, the full isolation of > > the time sub-system will have much higher overhead than just offsets for > > a few clocks. And the idea that isolation of the real-time clock should > > be optional gives us another hint that offsets for monotonic and > > boot-time clocks can be implemented independently. > > > > Eric and Tomas, what do you think about this? If you agree that these > > two cases can be implemented separately, what should we do with this > > series to make it ready to be merged? > > > > I know that we need to: > > > > * look at device drivers that report timestamps in CLOCK_MONOTONIC base. > > and CLOCK_BOOTTIME and that's quite a few. > > > * forbid changing offsets after creating timers > > There are more things to think about. What about interfaces which expose > boot time or monotonic time in /proc? We didn't find any proc files where boot or monotonic time is reported, but we will double check this. > > Aside of that (I finally came around to look at the series in more detail) > I'm really unhappy about the unconditional overhead once the Time namespace > config switch is enabled. This applies especially to the VDSO. We spent > quite some time recently to squeeze a few cycles out of those functions and > it would be a pity to pointlessly waste cycles for the !namespace case. It is a good point. We will work on it. > > I can see the urge for this, but please let us think it through properly > before rushing anything in which we are going to regret once we want to do > more sophisticated time domain management, e.g. support for isolated clock > real time. I'm worried, that without a clear plan about the overall > picture, we end up with duct tape which is hard to distangle after the > fact. Thomas, there is no rush at all. This functionality is critical for CRUI, but we have enough time to solve it properly. The only thing what I want is that this functionality continues moving forward and will not be put in the back burner. > > There have been a few other things brought up versus time management in > general, like the TSN folks utilizing grand clock masters which expose > random time instead of proper TAI. Plus some requirements for exposing some > sort of 'monotonic' clocks which are derived from external synchronization > mechanisms, but should not affect the regular time keeping clocks. > > While different issues, these all fall into the category of separate time > domains, so taking a step back to the drawing board is probably the best > thing what we can do now. > > There are certainly a few things which can be looked at independently, > e.g. the VDSO mechanics or general mechanisms to avoid plastering the whole > kernel with these name space functions applying offsets left and right. I > rather have dedicated core functionality which replaces/amends existing > timer functions to become time namespace aware. > > I'll try to find some time in the next weeks to look deeper into that, but > I can't promise anything before returning from LPC. Btw, LPC would be a > great opportunity to discuss that. Are you and the other name space wizards > there by any chance? Dmitry and I are going to be there. Thanks! Andrei > > Thanks, > > tglx > >