On Wed, 2014-07-30 at 00:31 -0700, tip-bot for John Stultz wrote:
Commit-ID: 953dec21aed4038464fec02f96a2f1b8701a5bce
Gitweb: http://git.kernel.org/tip/953dec21aed4038464fec02f96a2f1b8701a5bce
Author: John Stultz [off-list ref]
AuthorDate: Fri, 25 Jul 2014 21:37:19 -0700
Committer: Thomas Gleixner [off-list ref]
CommitDate: Wed, 30 Jul 2014 09:26:25 +0200
timekeeping: Fixup typo in update_vsyscall_old definition
In commit 4a0e637738f0 ("clocksource: Get rid of cycle_last"),
currently in the -tip tree, there was a small typo where cycles_t
was used intstead of cycle_t. This broke ppc64 builds.
There's another bug in there... You fix timespec vs. timespec64 for the
first argument of update_vsyscall_old but not the second one ...
(wall_to_monotonic).
Also, in e2dff1ec0 you claim this is "minor", you seem to forget that
arch/powerpc also deals with 32-bit kernels which use the same time
keeping code, so we have a pretty serious regressions here...
BTW. Is there some documentation you can point me to to figure out what
replace that "_OLD" stuff so we can update to whatever is "new" ?
Cheers,
Ben.
On 08/10/2014 09:19 PM, Benjamin Herrenschmidt wrote:
On Wed, 2014-07-30 at 00:31 -0700, tip-bot for John Stultz wrote:
quoted
Commit-ID: 953dec21aed4038464fec02f96a2f1b8701a5bce
Gitweb: http://git.kernel.org/tip/953dec21aed4038464fec02f96a2f1b8=
701a5bce
quoted
Author: John Stultz [off-list ref]
AuthorDate: Fri, 25 Jul 2014 21:37:19 -0700
Committer: Thomas Gleixner [off-list ref]
CommitDate: Wed, 30 Jul 2014 09:26:25 +0200
timekeeping: Fixup typo in update_vsyscall_old definition
In commit 4a0e637738f0 ("clocksource: Get rid of cycle_last"),
currently in the -tip tree, there was a small typo where cycles_t
was used intstead of cycle_t. This broke ppc64 builds.
There's another bug in there... You fix timespec vs. timespec64 for the=
first argument of update_vsyscall_old but not the second one ...
(wall_to_monotonic).
Also, in e2dff1ec0 you claim this is "minor", you seem to forget that
arch/powerpc also deals with 32-bit kernels which use the same time
keeping code, so we have a pretty serious regressions here...
Yikes. My apologies. I had missed that issue and had forgotten ppc32 has
the vsyscall support as well.
Thanks for pointing it out. I'll send a fix here shortly (though I only
have the ppc64le toolchain handy, so forgive me if its not quite right).
BTW. Is there some documentation you can point me to to figure out what=
replace that "_OLD" stuff so we can update to whatever is "new" ?
So there's not exactly documentation, but the idea is rather then doing:
nsecs + (mult*(now - cycle_last) >>shift);
We're preserving the sub-nanosecond precision, and doing:
(shifted_nsecs + mult*(now-cycle_last)) >> shift
This avoids the rounding up 1ns every tick, which we did to avoid errors
from truncating the precision.
I think the hard part for ppc, is if I recall, ppc's vsyscall exports
the xsec unit, which less granular then nanoseconds, so it had its own
version of the same precision truncation issues. I recall Paul working
on that, and I thought his solution was to reduce the multiplier by one
so the inter-tick time was slightly slower, then the tick update would
catch up causing a slight stair-step, which isn't ideal but is better
then the inconsistencies that came out of not-handling the precision
properly. That said, skimming the ppc code, I don't see that logic right
off, and have a fuzzy memory that maybe that solution was RHEL5 specific
or something like that.
thanks
-john
On Tue, Aug 12, 2014 at 08:30:40AM -0700, John Stultz wrote:
Thanks for pointing it out. I'll send a fix here shortly (though I only
have the ppc64le toolchain handy, so forgive me if its not quite right).
/me pimps the kernel.org toolchains:
https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/x86_64-gcc-4.9.0-nolibc_powerpc64-linux.tar.xz
and gets back in his box.
Yours Tony