Files
tegra-linux-noble/include/linux
Paul E. McKenney aa9b16306e rcu: Precompute RCU_FAST_NO_HZ timer offsets
When a CPU is entering dyntick-idle mode, tick_nohz_stop_sched_tick()
calls rcu_needs_cpu() see if RCU needs that CPU, and, if not, computes the
next wakeup time based on the timer wheels.  Only later, when actually
entering the idle loop, rcu_prepare_for_idle() will be invoked.  In some
cases, rcu_prepare_for_idle() will post timers to wake the CPU back up.
But all for naught: The next wakeup time for the CPU has already been
computed, and posting a timer afterwards does not force that wakeup
time to be recomputed.  This means that rcu_prepare_for_idle()'s have
no effect.

This is not a problem on a busy system because something else will wake
up the CPU soon enough.  However, on lightly loaded systems, the CPU
might stay asleep for a considerable length of time.  If that CPU has
a callback that the rest of the system is waiting on, the system might
run very slowly or (in theory) even hang.

This commit avoids this problem by having rcu_needs_cpu() give
tick_nohz_stop_sched_tick() an estimate of when RCU will need the CPU
to wake back up, which tick_nohz_stop_sched_tick() takes into account
when programming the CPU's wakeup time.  An alternative approach is
for rcu_prepare_for_idle() to use hrtimers instead of normal timers,
but timers are much more efficient than are hrtimers for frequently
and repeatedly posting and cancelling a given timer, which is exactly
what RCU_FAST_NO_HZ does.

Reported-by: Pascal Chapperon <pascal.chapperon@wanadoo.fr>
Reported-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Tested-by: Pascal Chapperon <pascal.chapperon@wanadoo.fr>
2012-06-06 20:43:28 -07:00
..
2012-05-07 15:39:35 -07:00
2012-04-23 14:23:32 +03:00
2012-05-15 17:30:30 -04:00
2012-05-08 14:13:25 -07:00
2012-03-29 15:38:31 +10:30
2012-03-23 16:58:38 -07:00
2012-04-14 15:24:26 -04:00
2012-05-02 14:15:27 -05:00
2012-05-25 12:46:23 +05:30
2012-05-10 12:00:56 +02:00
2012-04-30 15:30:18 -07:00
2012-05-17 15:36:35 -04:00
2012-05-29 23:28:33 -04:00
2012-04-12 12:57:08 +02:00
2012-04-27 10:46:45 +08:00
2012-05-22 11:32:31 +02:00
2012-03-26 21:47:19 +02:00
2012-03-26 21:47:19 +02:00
2012-03-26 21:47:19 +02:00
2012-05-12 14:28:14 +02:00
2012-03-26 21:47:19 +02:00
2012-03-27 22:45:26 -04:00
2012-04-21 16:26:33 -04:00
2012-05-07 10:58:57 -06:00
2012-05-21 21:09:38 +02:00
2012-04-09 11:16:55 -07:00
2012-05-31 17:49:30 -07:00
2012-05-31 17:49:32 -07:00
2012-05-31 17:49:26 -07:00
2012-05-31 17:49:30 -07:00
2012-05-11 10:56:56 +01:00
2012-05-29 23:28:41 -04:00
2012-05-09 13:58:06 -07:00
2012-05-22 15:20:28 -04:00
2012-05-29 16:22:19 -07:00
2012-05-29 22:33:55 -04:00
2012-05-08 20:25:42 +02:00
2012-04-12 15:10:33 -04:00
2012-05-26 14:17:30 -04:00
2012-05-16 15:17:08 -04:00
2012-05-21 14:31:48 +01:00
2012-03-21 17:55:01 -07:00
2012-05-14 14:15:32 -07:00
2012-05-12 15:53:42 -04:00
2012-05-17 08:51:59 -07:00
2012-03-28 18:30:03 +01:00
2012-04-18 15:57:31 -07:00
2012-06-01 12:58:52 -04:00
2012-05-31 17:49:26 -07:00
2012-05-08 12:35:06 +02:00
2012-04-15 12:44:40 -04:00
2012-05-14 18:53:19 -04:00
2012-05-29 16:22:28 -07:00
2012-05-21 16:16:58 -07:00
2012-03-22 19:43:43 -07:00
2012-05-22 12:16:16 +09:30
2012-03-31 08:09:50 +05:30
2012-03-28 18:30:03 +01:00