[PATCH v2 1/2] sched: let the scheduler see CPU idle states

From: Nicolas Pitre
Date: Thu Sep 04 2014 - 11:48:34 EST

From: Daniel Lezcano <daniel.lezcano@xxxxxxxxxx>

When the cpu enters idle, it stores the cpuidle state pointer in its
struct rq instance which in turn could be used to make a better decision
when balancing tasks.

As soon as the cpu exits its idle state, the struct rq reference is

There are a couple of situations where the idle state pointer could be changed
while it is being consulted:

1. For x86/acpi with dynamic c-states, when a laptop switches from battery
to AC that could result on removing the deeper idle state. The acpi driver

All cpus will exit their idle state and the pointed object will be set to

2. The cpuidle driver is unloaded. Logically that could happen but not
in practice because the drivers are always compiled in and 95% of them are
not coded to unregister themselves. In any case, the unloading code must
call 'cpuidle_unregister_device', that calls 'cpuidle_pause_and_lock'
leading to 'kick_all_cpus_sync' as mentioned above.

A race can happen if we use the pointer and then one of these two scenarios
occurs at the same moment.

In order to be safe, the idle state pointer stored in the rq must be
used inside a rcu_read_lock section where we are protected with the
'rcu_barrier' in the 'cpuidle_uninstall_idle_handler' function. The
idle_get_state() and idle_put_state() accessors should be used to that

Signed-off-by: Daniel Lezcano <daniel.lezcano@xxxxxxxxxx>
Signed-off-by: Nicolas Pitre <nico@xxxxxxxxxx>
drivers/cpuidle/cpuidle.c | 6 ++++++
kernel/sched/idle.c | 6 ++++++
kernel/sched/sched.h | 39 +++++++++++++++++++++++++++++++++++++++
3 files changed, 51 insertions(+)

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index ee9df5e3f5..530e3055a2 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -225,6 +225,12 @@ void cpuidle_uninstall_idle_handler(void)
initialized = 0;
+ /*
+ * Make sure external observers (such as the scheduler)
+ * are done looking at pointed idle states.
+ */
+ rcu_barrier();

diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index 11e7bc434f..c47fce75e6 100644
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -147,6 +147,9 @@ use_default:
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu))
goto use_default;

+ /* Take note of the planned idle state. */
+ idle_set_state(this_rq(), &drv->states[next_state]);
* Enter the idle state previously returned by the governor decision.
* This function will block until an interrupt occurs and will take
@@ -154,6 +157,9 @@ use_default:
entered_state = cpuidle_enter(drv, dev, next_state);

+ /* The cpu is no longer idle or about to enter idle. */
+ idle_set_state(this_rq(), NULL);
if (broadcast)
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);

diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 579712f4e9..aea8baa7a5 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -14,6 +14,7 @@
#include "cpuacct.h"

struct rq;
+struct cpuidle_state;

extern __read_mostly int scheduler_running;

@@ -636,6 +637,11 @@ struct rq {
struct llist_head wake_list;
+ /* Must be inspected within a rcu lock section */
+ struct cpuidle_state *idle_state;

static inline int cpu_of(struct rq *rq)
@@ -1180,6 +1186,39 @@ static inline void idle_exit_fair(struct rq *rq) { }


+static inline void idle_set_state(struct rq *rq,
+ struct cpuidle_state *idle_state)
+ rq->idle_state = idle_state;
+static inline struct cpuidle_state *idle_get_state(struct rq *rq)
+ rcu_read_lock();
+ return rq->idle_state;
+static inline void cpuidle_put_state(struct rq *rq)
+ rcu_read_unlock();
+static inline void idle_set_state(struct rq *rq,
+ struct cpuidle_state *idle_state)
+static inline struct cpuidle_state *idle_get_state(struct rq *rq)
+ return NULL;
+static inline void cpuidle_put_state(struct rq *rq)
extern void sysrq_sched_debug_show(void);
extern void sched_init_granularity(void);
extern void update_max_interval(void);

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/