On Thu, May 25, 2017 at 5:03 AM, Paul Mackerras wrote:
> On Mon, May 22, 2017 at 12:06:04PM -0700, John Stultz wrote:
>>
>> Basically long ago, timekeeping was handled (roughly) like:
>>
>> clock_gettime():
>> now = tk->clock->read()
>> offset_ns = ((now -
On Thu, May 25, 2017 at 5:03 AM, Paul Mackerras wrote:
> On Mon, May 22, 2017 at 12:06:04PM -0700, John Stultz wrote:
>>
>> Basically long ago, timekeeping was handled (roughly) like:
>>
>> clock_gettime():
>> now = tk->clock->read()
>> offset_ns = ((now - tk->cycle_last) *
On Mon, May 22, 2017 at 12:06:04PM -0700, John Stultz wrote:
>
> Basically long ago, timekeeping was handled (roughly) like:
>
> clock_gettime():
> now = tk->clock->read()
> offset_ns = ((now - tk->cycle_last) * tk->clock->mult) >>
> tk->clock->shift;
> return
On Mon, May 22, 2017 at 12:06:04PM -0700, John Stultz wrote:
>
> Basically long ago, timekeeping was handled (roughly) like:
>
> clock_gettime():
> now = tk->clock->read()
> offset_ns = ((now - tk->cycle_last) * tk->clock->mult) >>
> tk->clock->shift;
> return
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
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
On Mon, 2017-05-22 at 12:06 -0700, John Stultz wrote:
> 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).
On Mon, 2017-05-22 at 12:06 -0700, John Stultz wrote:
> 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).
On Sun, May 21, 2017 at 5:58 PM, Michael Ellerman wrote:
> John Stultz writes:
>
>> CONFIG_GENERIC_TIME_VSYSCALL_OLD was introduced five years ago
>> to allow a transition from the old vsyscall implementations to
>> the new method (which simplified
On Sun, May 21, 2017 at 5:58 PM, Michael Ellerman wrote:
> John Stultz writes:
>
>> CONFIG_GENERIC_TIME_VSYSCALL_OLD was introduced five years ago
>> to allow a transition from the old vsyscall implementations to
>> the new method (which simplified internal accounting and made
>> timekeeping
John Stultz writes:
> CONFIG_GENERIC_TIME_VSYSCALL_OLD was introduced five years ago
> to allow a transition from the old vsyscall implementations to
> the new method (which simplified internal accounting and made
> timekeeping more precise).
I'm sure it's completely
John Stultz writes:
> CONFIG_GENERIC_TIME_VSYSCALL_OLD was introduced five years ago
> to allow a transition from the old vsyscall implementations to
> the new method (which simplified internal accounting and made
> timekeeping more precise).
I'm sure it's completely obvious to everyone except
CONFIG_GENERIC_TIME_VSYSCALL_OLD was introduced five years ago
to allow a transition from the old vsyscall implementations to
the new method (which simplified internal accounting and made
timekeeping more precise).
However, PPC and IA64 have yet to make the transition, despite
in some cases me
CONFIG_GENERIC_TIME_VSYSCALL_OLD was introduced five years ago
to allow a transition from the old vsyscall implementations to
the new method (which simplified internal accounting and made
timekeeping more precise).
However, PPC and IA64 have yet to make the transition, despite
in some cases me
14 matches
Mail list logo