Skip to content

Commit 1842f5a

Browse files
Sebastian Andrzej SiewiorKAGA-KOKO
authored andcommitted
hrtimer: Determine hard/soft expiry mode for hrtimer sleepers on RT
On PREEMPT_RT enabled kernels hrtimers which are not explicitely marked for hard interrupt expiry mode are moved into soft interrupt context either for latency reasons or because the hrtimer callback takes regular spinlocks or invokes other functions which are not suitable for hard interrupt context on PREEMPT_RT. The hrtimer_sleeper callback is RT compatible in hard interrupt context, but there is a latency concern: Untrusted userspace can spawn many threads which arm timers for the same expiry time on the same CPU. On expiry that causes a latency spike due to the wakeup of a gazillion threads. OTOH, priviledged real-time user space applications rely on the low latency of hard interrupt wakeups. These syscall related wakeups are all based on hrtimer sleepers. If the current task is in a real-time scheduling class, mark the mode for hard interrupt expiry. [ tglx: Split out of a larger combo patch. Added changelog ] Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Steven Rostedt (VMware) <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
1 parent f5c2f02 commit 1842f5a

File tree

1 file changed

+34
-0
lines changed

1 file changed

+34
-0
lines changed

kernel/time/hrtimer.c

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1676,13 +1676,47 @@ static enum hrtimer_restart hrtimer_wakeup(struct hrtimer *timer)
16761676
void hrtimer_sleeper_start_expires(struct hrtimer_sleeper *sl,
16771677
enum hrtimer_mode mode)
16781678
{
1679+
/*
1680+
* Make the enqueue delivery mode check work on RT. If the sleeper
1681+
* was initialized for hard interrupt delivery, force the mode bit.
1682+
* This is a special case for hrtimer_sleepers because
1683+
* hrtimer_init_sleeper() determines the delivery mode on RT so the
1684+
* fiddling with this decision is avoided at the call sites.
1685+
*/
1686+
if (IS_ENABLED(CONFIG_PREEMPT_RT) && sl->timer.is_hard)
1687+
mode |= HRTIMER_MODE_HARD;
1688+
16791689
hrtimer_start_expires(&sl->timer, mode);
16801690
}
16811691
EXPORT_SYMBOL_GPL(hrtimer_sleeper_start_expires);
16821692

16831693
static void __hrtimer_init_sleeper(struct hrtimer_sleeper *sl,
16841694
clockid_t clock_id, enum hrtimer_mode mode)
16851695
{
1696+
/*
1697+
* On PREEMPT_RT enabled kernels hrtimers which are not explicitely
1698+
* marked for hard interrupt expiry mode are moved into soft
1699+
* interrupt context either for latency reasons or because the
1700+
* hrtimer callback takes regular spinlocks or invokes other
1701+
* functions which are not suitable for hard interrupt context on
1702+
* PREEMPT_RT.
1703+
*
1704+
* The hrtimer_sleeper callback is RT compatible in hard interrupt
1705+
* context, but there is a latency concern: Untrusted userspace can
1706+
* spawn many threads which arm timers for the same expiry time on
1707+
* the same CPU. That causes a latency spike due to the wakeup of
1708+
* a gazillion threads.
1709+
*
1710+
* OTOH, priviledged real-time user space applications rely on the
1711+
* low latency of hard interrupt wakeups. If the current task is in
1712+
* a real-time scheduling class, mark the mode for hard interrupt
1713+
* expiry.
1714+
*/
1715+
if (IS_ENABLED(CONFIG_PREEMPT_RT)) {
1716+
if (task_is_realtime(current) && !(mode & HRTIMER_MODE_SOFT))
1717+
mode |= HRTIMER_MODE_HARD;
1718+
}
1719+
16861720
__hrtimer_init(&sl->timer, clock_id, mode);
16871721
sl->timer.function = hrtimer_wakeup;
16881722
sl->task = current;

0 commit comments

Comments
 (0)