linux-stable.git/include/linux/hrtimer.h, branch v3.16.85

hrtimer: Get rid of the resolution field in hrtimer_clock_base

2020-02-11T20:03:54+00:00

commit 398ca17fb54b212cdc9da7ff4a17a35c48dd2103 upstream.

The field has no value because all clock bases have the same
resolution. The resolution only changes when we switch to high
resolution timer mode. We can evaluate that from a single static
variable as well. In the !HIGHRES case its simply a constant.

Export the variable, so we can simplify the usage sites.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Preeti U Murthy 
Acked-by: Peter Zijlstra 
Cc: Viresh Kumar 
Cc: Marcelo Tosatti 
Cc: Frederic Weisbecker 
Link: http://lkml.kernel.org/r/20150414203500.645454122@linutronix.de
Signed-off-by: Thomas Gleixner 
[bwh: Backported to 3.16 as dependency of commit 552263456215
 "powerpc: Fix vDSO clock_getres()":
 - Adjust filename, context]
Signed-off-by: Ben Hutchings

hrtimer: Store cpu-number in struct hrtimer_cpu_base

2019-12-19T15:57:47+00:00

commit cddd02489f52ccf635ed65931214729a23b93cd6 upstream.

In lowres mode, hrtimers are serviced by the tick instead of a clock
event. Now it works well as long as the tick stays periodic but we
must also make sure that the hrtimers are serviced in dynticks mode.

Part of that job consist in kicking a dynticks hrtimer target in order
to make it reconsider the next tick to schedule to correctly handle the
hrtimer's expiring time. And that part isn't handled by the hrtimers
subsystem.

To prepare for fixing this, we need __hrtimer_start_range_ns() to be
able to resolve the CPU target associated to a hrtimer's object
'cpu_base' so that the kick can be centralized there.

So lets store it in the 'struct hrtimer_cpu_base' to resolve the CPU
without overhead. It is set once at CPU's online notification.

Signed-off-by: Viresh Kumar 
Signed-off-by: Frederic Weisbecker 
Link: http://lkml.kernel.org/r/1403393357-2070-4-git-send-email-fweisbec@gmail.com
Signed-off-by: Thomas Gleixner 
[bwh: Backported to 3.16 as dependency of commit b9023b91dd02
 "tick: broadcast-hrtimer: Fix a race in bc_set_next":
 - Adjust filename, context]
Signed-off-by: Ben Hutchings

hrtimer: Rearrange comments in the order struct members are declared

2014-03-20T11:35:45+00:00

Rearrange kernel doc comments in the order members of struct hrtimer are
declared.

Signed-off-by: Viresh Kumar 
Cc: linaro-kernel@lists.linaro.org
Cc: fweisbec@gmail.com
Cc: trivial@kernel.org
Link: http://lkml.kernel.org/r/1db1a3cfbe8a9ea49396af75c6ac04a2e67e3ab0.1395226248.git.viresh.kumar@linaro.org
Signed-off-by: Thomas Gleixner

hrtimer: Add hrtimer support for CLOCK_TAI

2013-03-22T23:19:59+00:00

Add hrtimer support for CLOCK_TAI, as well as posix timer interfaces.

Signed-off-by: John Stultz

timekeeping: Provide hrtimer update function

2012-07-11T21:34:39+00:00

To finally fix the infamous leap second issue and other race windows
caused by functions which change the offsets between the various time
bases (CLOCK_MONOTONIC, CLOCK_REALTIME and CLOCK_BOOTTIME) we need a
function which atomically gets the current monotonic time and updates
the offsets of CLOCK_REALTIME and CLOCK_BOOTTIME with minimalistic
overhead. The previous patch which provides ktime_t offsets allows us
to make this function almost as cheap as ktime_get() which is going to
be replaced in hrtimer_interrupt().

Signed-off-by: Thomas Gleixner 
Reviewed-by: Ingo Molnar 
Acked-by: Peter Zijlstra 
Acked-by: Prarit Bhargava 
Cc: stable@vger.kernel.org
Signed-off-by: John Stultz 
Link: http://lkml.kernel.org/r/1341960205-56738-7-git-send-email-johnstul@us.ibm.com
Signed-off-by: Thomas Gleixner

hrtimer: Provide clock_was_set_delayed()

2012-07-11T21:34:37+00:00

clock_was_set() cannot be called from hard interrupt context because
it calls on_each_cpu().

For fixing the widely reported leap seconds issue it is necessary to
call it from hard interrupt context, i.e. the timer tick code, which
does the timekeeping updates.

Provide a new function which denotes it in the hrtimer cpu base
structure of the cpu on which it is called and raise the hrtimer
softirq. We then execute the clock_was_set() notificiation from
softirq context in run_hrtimer_softirq(). The hrtimer softirq is
rarely used, so polling the flag there is not a performance issue.

[ tglx: Made it depend on CONFIG_HIGH_RES_TIMERS. We really should get
  rid of all this ifdeffery ASAP ]

Signed-off-by: John Stultz 
Reported-by: Jan Engelhardt 
Reviewed-by: Ingo Molnar 
Acked-by: Peter Zijlstra 
Acked-by: Prarit Bhargava 
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1341960205-56738-2-git-send-email-johnstul@us.ibm.com
Signed-off-by: Thomas Gleixner

Fix some kernel-doc warnings

2011-06-27T23:06:19+00:00

Fix 'make htmldocs' warnings:

  Warning(/include/linux/hrtimer.h:153): No description found for parameter 'clockid'
  Warning(/include/linux/device.h:604): Excess struct/union/enum/typedef member 'of_match' description in 'device'
  Warning(/include/net/sock.h:349): Excess struct/union/enum/typedef member 'sk_rmem_alloc' description in 'sock'

Signed-off-by: Vitaliy Ivanov 
Acked-by: Grant Likely 
Acked-by: David S. Miller 
Signed-off-by: Linus Torvalds

hrtimers: Reorder clock bases

2011-05-23T11:59:54+00:00

The ordering of the clock bases is historical due to the
CLOCK_REALTIME and CLOCK_MONOTONIC constants. Now the hrtimer bases
have their own enumeration due to the gap between CLOCK_MONOTONIC and
CLOCK_BOOTTIME. So we can be more clever as most timers end up on the
CLOCK_MONOTONIC base due to the virtue of POSIX declaring that
relative CLOCK_REALTIME timers are not affected by time changes. In
desktop environments this is slowly changing as applications switch to
absolute timers, but I've observed empty CLOCK_REALTIME bases often
enough. There is no performance penalty or overhead when
CLOCK_REALTIME timers are active, but in case they are not we don't
skip over a full cache line.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Peter Zijlstra

hrtimers: Avoid touching inactive timer bases

2011-05-23T11:59:54+00:00

Instead of iterating over all possible timer bases avoid it by marking
the active bases in the cpu base.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Peter Zijlstra

hrtimers: Make struct hrtimer_cpu_base layout less stupid

2011-05-23T11:59:53+00:00

In the HIGHRES=y case we access the members at the end of struct
hrtimer_cpu_base first and then the one at the beginning. Move the
hrtimer data to front, so we have linear progressing access.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Peter Zijlstra