Revert "hrtimer: Prevent enqueue of hrtimer on dead CPU"

This reverts commit 878f1bd9ddd4b9734ad72d187b0266e640c99e08.

Based on upstream mailing list discussions, this patch is not
necessary since switch_hrtimer_base() is called with interrupts
disabled.

Change-Id: I53c64b1a4cea3a310ef53d1729a00baee6e4534a
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Revert "hrtimer: Consider preemption when migrating hrtimer cpu_bases"

This reverts commit f31b9b9f30f76847c94155f9da4da12f912b0885.

Based on upstream mailing list discussions, this patch is not
necessary since switch_hrtimer_base() is called with interrupts
disabled.

Change-Id: I0244a744516e1c289af25043ee8b866be54813e3
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
freezer: skip waking up tasks with PF_FREEZER_SKIP set

Date	Wed, 1 May 2013 18:35:00 -0700

Android goes through suspend/resume very often (every few seconds when
on a busy wifi network with the screen off), and a significant portion
of the energy used to go in and out of suspend is spent in the
freezer.  If a task has called freezer_do_not_count(), don't bother
waking it up.  If it happens to wake up later it will call
freezer_count() and immediately enter the refrigerator.

Combined with patches to convert freezable helpers to use
freezer_do_not_count() and convert common sites where idle userspace
tasks are blocked to use the freezable helpers, this reduces the
time and energy required to suspend and resume.

Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
sched: Fix SCHED_HRTICK bug leading to late preemption of tasks

SCHED_HRTICK feature is useful to preempt SCHED_FAIR tasks on-the-dot
(just when they would have exceeded their ideal_runtime). It makes use
of a a per-cpu hrtimer resource and hence alarming that hrtimer should
be based on total SCHED_FAIR tasks a cpu has across its various cfs_rqs,
rather than being based on number of tasks in a particular cfs_rq (as
implemented currently). As a result, with current code, its possible for
a running task (which is the sole task in its cfs_rq) to be preempted
much after its ideal_runtime has elapsed, resulting in increased latency
for tasks in other cfs_rq on same cpu.

Fix this by alarming sched hrtimer based on total number of SCHED_FAIR
tasks a CPU has across its various cfs_rqs.

Change-Id: I1f23680a64872f8ce0f451ac4bcae28e8967918f
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
sched: Reset rq->next_interval before going idle

next_balance, the point in jiffy time scale when a cpu will next load
balance, could have been calculated when the cpu was busy. A busy cpu
will apply its sched domain's busy_factor (usually > 1) in computing
next_balance for that sched domain, which causes the (busy) cpu to load
balance less frequently in its sched domains. However when the same cpu
is going idle, its next_balance needs to be reset without consideration
of busy_factor. Failure to do so would not trigger nohz idle balancer on
that cpu for unnecessarily long time (introducing additional scheduling
latencies for tasks). Fix bug in scheduler which aims to reset
next_balance before a cpu goes idle (as per existing comment) but is
clearly not doing so.

Change-Id: I7e027a51686528c4092d770c7d33c874d38f5df4
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>