hrtimer: Store running timer in hrtimer_clock_base
authorAnna-Maria Gleixner <anna-maria@linutronix.de>
Thu, 21 Dec 2017 10:41:40 +0000 (11:41 +0100)
committerIngo Molnar <mingo@kernel.org>
Tue, 16 Jan 2018 01:35:46 +0000 (02:35 +0100)
commit3f0b9e8eec7262648ab9c8321bf931624ee5c10a
tree0d5a376e2c7d1c27a6f1969d7816938ca6ed797b
parentc272ca58c3ec5631f4ab507489d9477f74efe645
hrtimer: Store running timer in hrtimer_clock_base

The pointer to the currently running timer is stored in hrtimer_cpu_base
before the base lock is dropped and the callback is invoked.

This results in two levels of indirections and the upcoming support for
softirq based hrtimer requires splitting the "running" storage into soft
and hard IRQ context expiry.

Storing both in the cpu base would require conditionals in all code paths
accessing that information.

It's possible to have a per clock base sequence count and running pointer
without changing the semantics of the related mechanisms because the timer
base pointer cannot be changed while a timer is running the callback.

Unfortunately this makes cpu_clock base larger than 32 bytes on 32-bit
kernels. Instead of having huge gaps due to alignment, remove the alignment
and let the compiler pack CPU base for 32-bit kernels. The resulting cache access
patterns are fortunately not really different from the current
behaviour. On 64-bit kernels the 64-byte alignment stays and the behaviour is
unchanged. This was determined by analyzing the resulting layout and
looking at the number of cache lines involved for the frequently used
clocks.

Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
Cc: Christoph Hellwig <hch@lst.de>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: keescook@chromium.org
Link: http://lkml.kernel.org/r/20171221104205.7269-12-anna-maria@linutronix.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
include/linux/hrtimer.h
kernel/time/hrtimer.c