From: Andrew Morton on
On Tue, 6 Apr 2010 14:30:51 -0700 John Stultz <johnstul(a)us.ibm.com> wrote:

> Thomas: Mind queueing this up for 2.6.35?
>
> With the earlier logarithmic time accumulation patch, xtime will now
> always be within one "tick" of the current time, instead of possibly
> half a second off.
>
> This removes the need for the xtime_cache value, which always stored the
> time at the last interrupt, so this patch cleans that up removing the
> xtime_cache related code.
>
> This patch also addresses an issue with an earlier version of this change,
> where xtime_cache was normalizing xtime, which could in some cases be
> not valid (ie: tv_nsec == NSEC_PER_SEC). This is fixed by handling
> the edge case in update_wall_time().
>
> ...
>
> --- a/kernel/time.c
> +++ b/kernel/time.c
> @@ -135,7 +135,6 @@ static inline void warp_clock(void)
> write_seqlock_irq(&xtime_lock);
> wall_to_monotonic.tv_sec -= sys_tz.tz_minuteswest * 60;
> xtime.tv_sec += sys_tz.tz_minuteswest * 60;
> - update_xtime_cache(0);
> write_sequnlock_irq(&xtime_lock);
> clock_was_set();
> }

This conflicts with your time-clean-up-warp_clock.patch, below.

Shrug, I simply ignored the rejected hunk.



From: John Stultz <johnstul(a)us.ibm.com>

warp_clock() currently accesses timekeeping internal state directly, which
is unnecessary. Convert it to use the proper timekeeping interfaces.

Signed-off-by: John Stultz <johnstul(a)us.ibm.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Ingo Molnar <mingo(a)elte.hu>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---

kernel/time.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)

diff -puN kernel/time.c~time-clean-up-warp_clock kernel/time.c
--- a/kernel/time.c~time-clean-up-warp_clock
+++ a/kernel/time.c
@@ -132,12 +132,11 @@ SYSCALL_DEFINE2(gettimeofday, struct tim
*/
static inline void warp_clock(void)
{
- write_seqlock_irq(&xtime_lock);
- wall_to_monotonic.tv_sec -= sys_tz.tz_minuteswest * 60;
- xtime.tv_sec += sys_tz.tz_minuteswest * 60;
- update_xtime_cache(0);
- write_sequnlock_irq(&xtime_lock);
- clock_was_set();
+ struct timespec delta, adjust;
+ delta.tv_sec = sys_tz.tz_minuteswest * 60;
+ delta.tv_nsec = 0;
+ adjust = timespec_add_safe(current_kernel_time(), delta);
+ do_settimeofday(&adjust);
}

/*
_

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: john stultz on
On Mon, 2010-04-12 at 21:00 -0400, Andrew Morton wrote:
> On Tue, 6 Apr 2010 14:30:51 -0700 John Stultz <johnstul(a)us.ibm.com> wrote:
>
> > Thomas: Mind queueing this up for 2.6.35?
> >
> > With the earlier logarithmic time accumulation patch, xtime will now
> > always be within one "tick" of the current time, instead of possibly
> > half a second off.
> >
> > This removes the need for the xtime_cache value, which always stored the
> > time at the last interrupt, so this patch cleans that up removing the
> > xtime_cache related code.
> >
> > This patch also addresses an issue with an earlier version of this change,
> > where xtime_cache was normalizing xtime, which could in some cases be
> > not valid (ie: tv_nsec == NSEC_PER_SEC). This is fixed by handling
> > the edge case in update_wall_time().
> >
> > ...
> >
> > --- a/kernel/time.c
> > +++ b/kernel/time.c
> > @@ -135,7 +135,6 @@ static inline void warp_clock(void)
> > write_seqlock_irq(&xtime_lock);
> > wall_to_monotonic.tv_sec -= sys_tz.tz_minuteswest * 60;
> > xtime.tv_sec += sys_tz.tz_minuteswest * 60;
> > - update_xtime_cache(0);
> > write_sequnlock_irq(&xtime_lock);
> > clock_was_set();
> > }
>
> This conflicts with your time-clean-up-warp_clock.patch, below.
>
> Shrug, I simply ignored the rejected hunk.

Yep. That should be fine. We're just dropping the update_xtime_cache
call, so if it doesn't exist, its not a problem.

thanks
-john

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/