Re: [PATCH RFC V1 0/5] Rationalize time keeping

[John Stultz <john.stultz@linaro.org>]

On 05/03/2012 11:21 AM, Richard Cochran wrote:
> On Fri, Apr 27, 2012 at 03:49:51PM -0700, John Stultz wrote:
>> On 04/27/2012 01:12 AM, Richard Cochran wrote:
>>> * Performance Impacts
>>> ** con
>>>     - Small extra cost when reading the time (one integer addition plus
>>>       one integer test).
>> This may not be so small when it comes to folks who are very
>> concerned about the clock_gettime hotpath.
>> Further, the correction will be needed to be made in the vsyscall
>> paths, which isn't done with your current patchset (causing userland
>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> to see different time values then what kernel space calculates).
> John, now that you clarified the vDSO thing, I am very confused about
> this statement of yours. It appears that the vDSO data are updated
> when timekeeping_update() in timekeeper.c calls update_vsyscall().
>
> I think the hunk from patch #5, below, does in fact adjust the time
> value correctly before it gets handed off to the arch-specific
> update_vsyscall() to be copied into the vDSO page. So I'll make the
> claim that:
>
> 1. We don't have to touch the vsyscall paths for this.
> 2. This change does not affect vDSO performance at all.
>
But the changes you make to getnstimeofday() still needs to happen in 
the vDSO code. The vDSO code basically implements getnstimeofday() in 
userland.

If you're code is trying to make it so that the leap-second is properly 
handled at the second boundary instead of the tick boundary, there must 
me some change needed to the vDSO, since the vDSO code is updated only 
each tick. Otherwise how can you enforce the leap after the second 
boundary but before the tick?

thanks
-john