From: Michael Ellerman <mpe@ellerman.id.au>
To: John Stultz <john.stultz@linaro.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@kernel.org>,
Miroslav Lichvar <mlichvar@redhat.com>,
Richard Cochran <richardcochran@gmail.com>,
Prarit Bhargava <prarit@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
Paul Mackerras <paulus@samba.org>,
Anton Blanchard <anton@samba.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>
Subject: Re: [RFC][PATCH] time: Add warning about imminent deprecation of CONFIG_GENERIC_TIME_VSYSCALL_OLD
Date: Wed, 24 May 2017 23:31:44 +1000 [thread overview]
Message-ID: <87inkq9y9r.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <CALAqxLV4AeGnxSjRqsN4Oge4+KHJ6gxm3oXM+uNEx6btuAc2wA@mail.gmail.com>
John Stultz <john.stultz@linaro.org> 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
next prev parent reply other threads:[~2017-05-24 13:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-12 18:24 John Stultz
2017-05-22 0:58 ` Michael Ellerman
2017-05-22 19:06 ` John Stultz
2017-05-22 20:45 ` Benjamin Herrenschmidt
2017-05-24 13:31 ` Michael Ellerman [this message]
2017-05-25 12:03 ` Paul Mackerras
2017-05-27 3:58 ` John Stultz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87inkq9y9r.fsf@concordia.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=anton@samba.org \
--cc=benh@kernel.crashing.org \
--cc=fenghua.yu@intel.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mlichvar@redhat.com \
--cc=mtosatti@redhat.com \
--cc=paulus@samba.org \
--cc=prarit@redhat.com \
--cc=richardcochran@gmail.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®