cpufreq: ondemand: update from semaphore upstream
lowmemorykiller: make default lowmemorykiller debug message useful

lowmemorykiller debug messages are inscrutable and mostly useful
for debugging the lowmemorykiller, not explaining why a process
was killed.  Make the messages more useful by prefixing them
with "lowmemorykiller: " and explaining in more readable terms
what was killed, who it was killed for, and why it was killed.

The messages now look like:
[   76.997631] lowmemorykiller: Killing 'droid.gallery3d' (2172), adj 1000,
[   76.997635]    to free 27436kB on behalf of 'kswapd0' (29) because
[   76.997638]    cache 122624kB is below limit 122880kB for oom_score_adj 1000
[   76.997641]    Free memory is -53356kB above reserved

A negative number for free memory above reserved means some of the
reserved memory has been used and is being regenerated by kswapd,
which is likely what called the shrinkers.

Change-Id: I1fe983381e73e124b90aa5d91cb66e55eaca390f
Signed-off-by: Colin Cross <ccross@android.com>
android/lowmemorykiller: Account for total_swapcache_pages

The lowmemorykiller relies on NR_FILE_PAGES when measureing
the amount of reclaimable memory in the system.
However when swap is enabled swap cache pages are counted
in NR_FILE_PAGES, and swap cache pages aren't as reclaimable
in low memory as file cache pages. Therefore a large swap
cache can result in the lowmemorykiller not running and
an OOM occuring.

In order to ensure the lowmemorykiller properly evaluates the
amount of reclaimable memory don't count the swap cache pages.

Change-Id: I38239283e572f814b277c718eaf6be7f92abacbb
Signed-off-by: Liam Mark <lmark@codeaurora.org>

Conflicts:
	drivers/staging/android/lowmemorykiller.c
lowmemorykiller: Account for highmem during kswapd reclaim

Currenlty most memory reclaim is done through kswapd.
Since kswapd uses a gfp mask of GFP_KERNEL, and because
the lowmemorykiller is zone aware, the lowmemorykiller will
ignore highmem most of the time.
This results in the lowmemorykiller being overly aggressive.

The fix to this issue is to allow the lowmemorykiller to
count highmem when being called by the kswapd if the lowmem
watermarks are satisfied.

Change-Id: I938644584f374763d10d429d835e74daa4854a38
Signed-off-by: Liam Mark <lmark@codeaurora.org>
(cherry picked from commit e738360cd6a03df15087c3aee750b66de4359a30)
Revert "lowmemorykiller: Don't count reserve page twice"

This reverts commit d73f05ceab2717c23f00bfeffa31a7dedd15569a.

The patch is causing device crash while running
kernel tests on mainline. The change was to
make LMK less aggressive.

Change-Id: I272bf5ccd54a29de1c770d69af7fea2963f46333
Signed-off-by: Susheel Khiani <skhiani@codeaurora.org>
lowmemorykiller: Don't count reserve page twice

This is essentially revert of
dc41a1c61a00f7f6213a6ff164495611fd283dbb
Revert "lowmemorykiller: Don't count reserve page twice"

We need to resolve double accounting of the reserve
pages. Lastly, we have reverted this suspecting this
as culprit of some issue. But the nature of this patch
is cleaner and solving real issue of mis-accounting.

Change-Id: I29debaa1bc05703205b323b458f2dfe2938fdfa9
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
msm: acpuclock-krait: Init to max speed

There's no need to delay the boot process by running at slower
speeds, let's boot at max speed to get to the UI faster.

Change-Id: I4f07e8ff7a73ba8add17611bb0875a231ab5a568
Signed-off-by: Chris Fries <C.Fries@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/531544
SLT-Approved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Christopher Fries <qcf001@motorola.com>
Reviewed-by: Check Patch <CHEKPACH@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Reviewed-by: Igor Kovalenko <cik009@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
[ljc: Adapt to use common ARCH_MSM8960]
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
Signed-off-by: poondog <markj338@gmail.com>
Signed-off-by: Lens-F <tnoah12@gmail.com>
msm: acpuclock-krait: Disable vdd core boost
msm: cpufreq: Break out early if target frequency is the same as the current

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
cgroup: Take css_set_lock from cgroup_css_sets_empty()

As indicated in the comment above cgroup_css_sets_empty it needs the
css_set_lock. But neither of the 2 call points have it, so rather then fixing
the callers just take the lock inside cgroup_css_sets_empty().

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Change-Id: If7aea71824f6d0e3f2cc6c1ce236c3ae6be2037b
cgroup: Fix use after free of cgrp (cgrp->css_sets)

Running a 3.4 kernel + Fedora-18 (systemd) userland on my Allwinner A10
(arm cortex a8), I'm seeing repeated, reproducable list_del list corruption
errors when build with CONFIG_DEBUG_LIST, and the backtrace always shows
free_css_set_work as the function making the problematic list_del call.

I've tracked this doen to a use after free of the cgrp struct, specifically
of the cgrp->css_sets list_head, which gets cleared by free_css_set_work.

Since free_css_set_work runs form a workqueue, it is possible for it to not be
done with clearing the list when the cgrp gets free-ed. To avoid this the code
adding the links increases cgrp->count, and the freeing code running from the
workqueue decreases cgrp->count *after* doing list_del, and then if the count
goes to 0 calls cgroup_wakeup_rmdir_waiter().

However cgroup_rmdir() is missing a check for cgrp->count != 0, causing it
to still continue with the rmdir (which leads to the free-ing of the cgrp),
before free_css_set_work is done. Sometimes the free-ed memory is re-used
before free_css_set_work gets around to unlinking link->cgrp_link_list,
triggering the list_del list corruption messages.

This patch fixes this by properly checking for cgrp->count != 0 and waiting
for the cgroup_rmdir_waitq in that case.

Change-Id: I9dbc02a0a75d5dffa1b65d67456e00139dea57c3
Signed-off-by: Hans de Goede <hdegoede@redhat.com>