Enable CONFIG_MODULES

Signed-off-by: Seongmin Park <r_data@naver.com>
Revert "hrtimer: Prevent enqueue of hrtimer on dead CPU"

This reverts commit 41521264e204354a9adfc9b00839ee467f31627e.
Revert "hrtimer: Consider preemption when migrating hrtimer cpu_bases"

This reverts commit 4e059ca4fd8589d4925a39335a326c6ecb3b99ac.
Revert "Revert "scheduler: compute time-average nr_running per run-queue""

This reverts commit e3ac5179110f630c110131b100b84650ebe4ad5c.
Revert "Revert "scheduler: Re-compute time-average nr_running on read""

This reverts commit ec1f0539374a2615247e3129e0571a879e9b6785.
hrtimer: Consider preemption when migrating hrtimer cpu_bases

Date	Wed, 10 Apr 2013 14:07:47 -0700

When switching to a new cpu_base in switch_hrtimer_base(), we
briefly enable preemption by unlocking the cpu_base lock in two
places. During this interval it's possible for the running thread
to be swapped to a different CPU.

Consider the following example:

CPU #0                                 CPU #1
----                                   ----
hrtimer_start()                        ...
 lock_hrtimer_base()
 switch_hrtimer_base()
  this_cpu = 0;
  target_cpu_base = 0;
  raw_spin_unlock(&cpu_base->lock)
<migrate to CPU 1>
...                                    this_cpu == 0
                                       cpu == this_cpu
                                       timer->base = CPU #0
                                       timer->base != LOCAL_CPU
Since the cached this_cpu is no longer accurate, we'll skip the
hrtimer_check_target() check. Once we eventually go to program
the hardware, we'll decide not to do so since it knows the real
CPU that we're running on is not the same as the chosen base. As
a consequence, we may end up missing the hrtimer's deadline.

Fix this by updating the local CPU number each time we retake a
cpu_base lock in switch_hrtimer_base().

Another possibility is to disable preemption across the whole of
switch_hrtimer_base. This looks suboptimal since preemption
would be disabled while waiting for lock(s).

Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Signed-off-by: Seongmin Park <r_data@naver.com>
hrtimer: Prevent enqueue of hrtimer on dead CPU

Date	Wed, 10 Apr 2013 14:07:48 -0700

When switching the hrtimer cpu_base, we briefly allow for
preemption to become enabled by unlocking the cpu_base lock.
During this time, the CPU corresponding to the new cpu_base
that was selected may in fact go offline. In this scenario, the
hrtimer is enqueued to a CPU that's not online, and therefore
it never fires.

As an example, consider this example:

CPU #0                          CPU #1
----                            ----
...                             hrtimer_start()
                                 lock_hrtimer_base()
                                 switch_hrtimer_base()
                                  cpu = hrtimer_get_target() -> 1
                                  spin_unlock(&cpu_base->lock)
                                <migrate thread to CPU #0>
                                <offline>
spin_lock(&new_base->lock)
this_cpu = 0
cpu != this_cpu
enqueue_hrtimer(cpu_base #1)
To prevent this scenario, verify that the CPU corresponding to
the new cpu_base is indeed online before selecting it in
hrtimer_switch_base(). If it's not online, fallback to using the
base of the current CPU.

Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Signed-off-by: Seongmin Park <r_data@naver.com>
Revert "cpufreq: Tune the FREQUENCY_DOWN_THRESHOLD"

This reverts commit 2eceb6ef3917a79a069edf139de1c47bd83953c2.
Revert "Revert "cpufreq: Tune the FREQUENCY_DOWN_THRESHOLD""

This reverts commit 0c9cd01ddc164b37fbdb1d65833b07231facecb0.
Revert "ARM CPU Topology -Enable SCHED_MC Signed-off-by: Seongmin Park <r_data@naver.com>"

This reverts commit e54e2b68fb9d03b3ad7050956b636cfb54d4c32a.