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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 24 Jan 2011 12:32:49 -0800
From:	john stultz <johnstul@...ibm.com>
To:	Torben Hohn <torbenh@....de>
Cc:	linux-kernel@...r.kernel.org, tglx@...utronix.de,
	hch@...radead.org, yong.zhang0@...il.com
Subject: Re: [PATCH 01/18] move do_timer() from kernel/timer.c into
 kernel/time/timekeeping.c

On Sat, 2011-01-22 at 00:06 +0100, Torben Hohn wrote:
> Signed-off-by: Torben Hohn <torbenh@....de>
> ---
>  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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/