From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1035501AbdEXNbx (ORCPT ); Wed, 24 May 2017 09:31:53 -0400 Received: from ozlabs.org ([103.22.144.67]:36125 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030953AbdEXNbu (ORCPT ); Wed, 24 May 2017 09:31:50 -0400 From: Michael Ellerman To: John Stultz Cc: lkml , Thomas Gleixner , Ingo Molnar , Miroslav Lichvar , Richard Cochran , Prarit Bhargava , Marcelo Tosatti , Paul Mackerras , Anton Blanchard , Benjamin Herrenschmidt , Tony Luck , Fenghua Yu Subject: Re: [RFC][PATCH] time: Add warning about imminent deprecation of CONFIG_GENERIC_TIME_VSYSCALL_OLD In-Reply-To: References: <1494613450-4713-1-git-send-email-john.stultz@linaro.org> <87y3tpso51.fsf@concordia.ellerman.id.au> User-Agent: Notmuch/0.21 (https://notmuchmail.org) Date: Wed, 24 May 2017 23:31:44 +1000 Message-ID: <87inkq9y9r.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org John Stultz writes: ... > So, long ago I talked w/ Paul Mackerras about the ppc vdso code, as > ppc has some other legacy "userspace time" code that has to be > maintained as well (I believe there's not code page, just data page > that userspace pulls directly from). So for that case, we have the > problem where we can't do this sub-ns accounting, so the hack there is > rather then rounding-up and adding to ntp_error in the accumulation > code (which then causes the mult to slow), we're basically doing it > in the reader, slowing down mult by one. This will cause userspace > time to have "steps" where after an accumulation time jumps forward a > bit, but avoids the possibility of a discontinuity where time jumps > backwards. > > But again, I don't want to pretend I'm not an expert on the ppc side. > This draft patch doesn't even touch the __kernel_clock_gettime() > implementations, and was trying to preserve the existing ppc logic > while transitioning the core code. Its likely that a better fix should > be done deeper in the ppc side (likely splitting the legacy userspace > data formats out so any hacks only apply to them). Thanks for all the detail, that's very helpful. We do export a bunch of values directly to userspace, so we'll have to come up with some way of making those continue to work, while updating things enough to unblock the generic code. Hopefully I can get Paul interested enough to look at it :) cheers