From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752416AbbKKLvo (ORCPT ); Wed, 11 Nov 2015 06:51:44 -0500 Received: from smtp02.citrix.com ([66.165.176.63]:13334 "EHLO SMTP02.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752165AbbKKLvm (ORCPT ); Wed, 11 Nov 2015 06:51:42 -0500 X-IronPort-AV: E=Sophos;i="5.20,275,1444694400"; d="scan'208";a="317370671" Date: Wed, 11 Nov 2015 11:51:26 +0000 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Thomas Gleixner CC: John Stultz , Stefano Stabellini , Arnd Bergmann , "linux-arm-kernel@lists.infradead.org" , , , Peter Zijlstra , lkml , Ingo Molnar Subject: Re: [PATCH v2 1/7] timekeeping: introduce __current_kernel_time64 In-Reply-To: Message-ID: References: <1447156675-7418-1-git-send-email-stefano.stabellini@eu.citrix.com> <4372800.FdTygmcuyo@wuerfel> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-DLP: MIA1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 10 Nov 2015, Thomas Gleixner wrote: > On Tue, 10 Nov 2015, John Stultz wrote: > > I'm sort of objecting to a different issue, where the > > __current_kernel_time() implementation probably shouldn't be grabbing > > the tk_core.timekeeper directly, and instead should take a passed > > pointer to a timekeeper. The vdso/pv_clock usage should have a > > timekeeper passed to them that they could use. > > That usage of __current_kernel_time() in that xen notifier is silly to > begin with. The notifier gets already called with a pointer to the > time keeper. That xen implementation just does not use it. > > We extract exactly that information in the vdso updates without > calling back into the core code. So for solving that xen thing we do > not need a 64 bit variant of __current_kernel_time() at all. The > notifier has the pointer to the timekeeper and can just grab data from > there. Many thanks for the suggestion, I'll do that. Should I open code tk_xtime in the xen notifier, or should I export it in timekeeper_internal.h? From mboxrd@z Thu Jan 1 00:00:00 1970 From: stefano.stabellini@eu.citrix.com (Stefano Stabellini) Date: Wed, 11 Nov 2015 11:51:26 +0000 Subject: [PATCH v2 1/7] timekeeping: introduce __current_kernel_time64 In-Reply-To: References: <1447156675-7418-1-git-send-email-stefano.stabellini@eu.citrix.com> <4372800.FdTygmcuyo@wuerfel> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, 10 Nov 2015, Thomas Gleixner wrote: > On Tue, 10 Nov 2015, John Stultz wrote: > > I'm sort of objecting to a different issue, where the > > __current_kernel_time() implementation probably shouldn't be grabbing > > the tk_core.timekeeper directly, and instead should take a passed > > pointer to a timekeeper. The vdso/pv_clock usage should have a > > timekeeper passed to them that they could use. > > That usage of __current_kernel_time() in that xen notifier is silly to > begin with. The notifier gets already called with a pointer to the > time keeper. That xen implementation just does not use it. > > We extract exactly that information in the vdso updates without > calling back into the core code. So for solving that xen thing we do > not need a 64 bit variant of __current_kernel_time() at all. The > notifier has the pointer to the timekeeper and can just grab data from > there. Many thanks for the suggestion, I'll do that. Should I open code tk_xtime in the xen notifier, or should I export it in timekeeper_internal.h? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: [PATCH v2 1/7] timekeeping: introduce __current_kernel_time64 Date: Wed, 11 Nov 2015 11:51:26 +0000 Message-ID: References: <1447156675-7418-1-git-send-email-stefano.stabellini@eu.citrix.com> <4372800.FdTygmcuyo@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Thomas Gleixner Cc: John Stultz , Stefano Stabellini , Arnd Bergmann , "linux-arm-kernel@lists.infradead.org" , xen-devel@lists.xensource.com, Ian.Campbell@citrix.com, Peter Zijlstra , lkml , Ingo Molnar List-Id: xen-devel@lists.xenproject.org On Tue, 10 Nov 2015, Thomas Gleixner wrote: > On Tue, 10 Nov 2015, John Stultz wrote: > > I'm sort of objecting to a different issue, where the > > __current_kernel_time() implementation probably shouldn't be grabbing > > the tk_core.timekeeper directly, and instead should take a passed > > pointer to a timekeeper. The vdso/pv_clock usage should have a > > timekeeper passed to them that they could use. > > That usage of __current_kernel_time() in that xen notifier is silly to > begin with. The notifier gets already called with a pointer to the > time keeper. That xen implementation just does not use it. > > We extract exactly that information in the vdso updates without > calling back into the core code. So for solving that xen thing we do > not need a 64 bit variant of __current_kernel_time() at all. The > notifier has the pointer to the timekeeper and can just grab data from > there. Many thanks for the suggestion, I'll do that. Should I open code tk_xtime in the xen notifier, or should I export it in timekeeper_internal.h?