Re: [PATCH 01/18] move do_timer() from kernel/timer.c intokernel/time/timekeeping.c

[john stultz]

On Sat, 2011-01-22 at 00:06 +0100, Torben Hohn wrote:
> Signed-off-by: Torben Hohn <torbenh@xxxxxx>
> ---
>  kernel/time/timekeeping.c |   12 ++++++++++++
>  kernel/timer.c            |   13 -------------
>  2 files changed, 12 insertions(+), 13 deletions(-)
> 
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index d27c756..546d82f 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -946,3 +946,15 @@ struct timespec get_monotonic_coarse(void)
>  				now.tv_nsec + mono.tv_nsec);
>  	return now;
>  }
> +
> +/*
> + * The 64-bit jiffies value is not atomic - you MUST NOT read it
> + * without sampling the sequence number in xtime_lock.
> + * jiffies is defined in the linker script...
> + */
> +void do_timer(unsigned long ticks)
> +{
> +	jiffies_64 += ticks;
> +	update_wall_time();
> +	calc_global_load(ticks);
> +}


I know Thomas suggested this move, but I'm not sure I agree (yet).
Jiffies updates, and load calculations really have much more to do with
the timer irq then with timekeeping, so I'd be prone to leave them in
place. Or maybe move them to the tick scheduling code?

I'm guessing Thomas is thinking to move these bits into timekeeping.c so
xtime_lock can be made static there, it just strikes me oddly.
Especially since jiffies access is still going to need the xtime_lock,
so we'd have to move all the jiffies code into timekeeping.c to do so.

Splitting the xtime_lock int a static timekeeper.lock and a static
jiffies_lock might be the clean way to divide things, but that really
just adds extra locking overhead. But maybe that's not much of an issue.

Thomas: I suspect I'm just not seeing where you're going with this.
Could you clarify a bit? :)

thanks
-john



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