Revert "cpufreq: Introduce new relation for freq selection"

This reverts commit abae3d21fa872e0a148a393d8567b82b6609c47e.
hotplug: add a up_frequency tunable

One of the main design goals of this driver was to provide
a generic approach of hotplugging. It turned out that powerful
cpus are unlikely to go all the way up to their max frequency
when under load.
This might be dua a wrongly configured cpu governor or just
because the device is too fast.
Adding a up_frequency tunable provides a simple a way to define
the frequency when the hotplug driver should care to online cpus.

By default, this is the max frequency reported by the cpu policy,
but can be changed to anything else.
One nice side-effect is that we only get the actual policy ones
instead of each sampling rate.

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
hotplug: rewrite sysfs entries

Since they all do the exact same thing, we can save
some lines and add a predefined macro for this.

Random cleanups are also included!

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
defconfig: temprarily disable kernel neon mode
defconfig: reclaim memmory from loggers
Added fsync on/off support.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>
fs: sync: enable fsync by default.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>
fs: sync: add missing return if fsync is disabled from userspace.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>
f2fs: backport performance improvements

This commit squashes in the following patches as backports:

- f2fs: skip unnecessary data writes during fsync
  https://github.com/torvalds/linux/commit/6d99ba41a72c1213f2029e6fc66aa7943339b5db

- f2fs: skip unnecessary node writes during fsync
  https://github.com/torvalds/linux/commit/479f40c44ae30e02642ce0391be707a53852d545

- f2fs: readahead multi pages of directory for performance
  https://github.com/torvalds/linux/commit/817202d937e6cca7e60f42e6495aaa51d70d9d7e

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
f2fs: partially revert last commit

https://github.com/torvalds/linux/commit/6d99ba41a72c1213f2029e6fc66aa7943339b5db
Requires a bit more of backport work, for now it seems
not necessary.

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
mm, oom: allow exiting threads to have access to memory reserves

Exiting threads, those with PF_EXITING set, can pagefault and require
memory before they can make forward progress.  This happens, for instance,
when a process must fault task->robust_list, a userspace structure, before
detaching its memory.

These threads also aren't guaranteed to get access to memory reserves
unless oom killed or killed from userspace.  The oom killer won't grant
memory reserves if other threads are also exiting other than current and
stalling at the same point.  This prevents needlessly killing processes
when others are already exiting.

Instead of special casing all the possible situations between PF_EXITING
getting set and a thread detaching its mm where it may allocate memory,
which probably wouldn't get updated when a change is made to the exit
path, the solution is to give all exiting threads access to memory
reserves if they call the oom killer.  This allows them to quickly
allocate, detach its mm, and free the memory it represents.

Summary of Luigi's bug report:

: He had an oom condition where threads were faulting on task->robust_list
: and repeatedly called the oom killer but it would defer killing a thread
: because it saw other PF_EXITING threads.  This can happen anytime we need
: to allocate memory after setting PF_EXITING and before detaching our mm;
: if there are other threads in the same state then the oom killer won't do
: anything unless one of them happens to be killed from userspace.
:
: So instead of only deferring for PF_EXITING and !task->robust_list, it's
: better to just give them access to memory reserves to prevent a potential
: livelock so that any other faults that may be introduced in the future in
: the exit path don't cause the same problem (and hopefully we don't allow
: too many of those!).

Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Tested-by: Luigi Semenzato <semenzato@google.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>
mm, oom: change type of oom_score_adj to short

The maximum oom_score_adj is 1000 and the minimum oom_score_adj is -1000,
so this range can be represented by the signed short type with no
functional change.  The extra space this frees up in struct signal_struct
will be used for per-thread oom kill flags in the next patch.

Signed-off-by: David Rientjes <rientjes@google.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Cc: Anton Vorontsov <anton.vorontsov@linaro.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>

Conflicts:
	drivers/staging/android/lowmemorykiller.c
	fs/proc/base.c
	include/linux/sched.h
	mm/oom_kill.c
	mm/swapfile.c
mm, oom: fix race when specifying a thread as the oom origin

test_set_oom_score_adj() and compare_swap_oom_score_adj() are used to
specify that current should be killed first if an oom condition occurs in
between the two calls.

The usage is

	short oom_score_adj = test_set_oom_score_adj(OOM_SCORE_ADJ_MAX);
	...
	compare_swap_oom_score_adj(OOM_SCORE_ADJ_MAX, oom_score_adj);

to store the thread's oom_score_adj, temporarily change it to the maximum
score possible, and then restore the old value if it is still the same.

This happens to still be racy, however, if the user writes
OOM_SCORE_ADJ_MAX to /proc/pid/oom_score_adj in between the two calls.
The compare_swap_oom_score_adj() will then incorrectly reset the old value
prior to the write of OOM_SCORE_ADJ_MAX.

To fix this, introduce a new oom_flags_t member in struct signal_struct
that will be used for per-thread oom killer flags.  KSM and swapoff can
now use a bit in this member to specify that threads should be killed
first in oom conditions without playing around with oom_score_adj.

This also allows the correct oom_score_adj to always be shown when reading
/proc/pid/oom_score.

Signed-off-by: David Rientjes <rientjes@google.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Cc: Anton Vorontsov <anton.vorontsov@linaro.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>

Conflicts:
	include/linux/sched.h
	mm/oom_kill.c
	mm/swapfile.c
oom: use N_MEMORY instead N_HIGH_MEMORY

N_HIGH_MEMORY stands for the nodes that has normal or high memory.
N_MEMORY stands for the nodes that has any memory.

The code here need to handle with the nodes which have memory, we should
use N_MEMORY instead.

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Acked-by: Hillf Danton <dhillf@gmail.com>
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Lin Feng <linfeng@cn.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>
mm, oom: cleanup pagefault oom handler

To lock the entire system from parallel oom killing, it's possible to pass
in a zonelist with all zones rather than using for_each_populated_zone()
for the iteration.  This obsoletes try_set_system_oom() and
clear_system_oom() so that they can be removed.

Signed-off-by: David Rientjes <rientjes@google.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>
mm, oom: remove redundant sleep in pagefault oom handler

out_of_memory() will already cause current to schedule if it has not been
killed, so doing it again in pagefault_out_of_memory() is redundant.
Remove it.

Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>
cpufreq: interactive: simplify the governor

This is based upon this work; https://github.com/franciscofranco/mako/commit/739f5159227ca3fa04a171d7cb7c7a90feb474a2
Although this contains still the tunable for
the sampling_down_factor. It also includes the array
for timer_slack.

Signed-off-by: Blechd0se <alex.christ@hotmail.de>

Conflicts:
	drivers/cpufreq/cpufreq_interactive.c
hotplug: add a up_frequency tunable

One of the main design goals of this driver was to provide
a generic approach of hotplugging. It turned out that powerful
cpus are unlikely to go all the way up to their max frequency
when under load.
This might be dua a wrongly configured cpu governor or just
because the device is too fast.
Adding a up_frequency tunable provides a simple a way to define
the frequency when the hotplug driver should care to online cpus.

By default, this is the max frequency reported by the cpu policy,
but can be changed to anything else.
One nice side-effect is that we only get the actual policy ones
instead of each sampling rate.

Signed-off-by: Blechd0se <alex.christ@hotmail.de>

Conflicts:
	arch/arm/kernel/aero_hotplug.c
hotplug: rewrite sysfs entries

Since they all do the exact same thing, we can save
some lines and add a predefined macro for this.

Random cleanups are also included!

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
msm: add userspace undervolting interface

First of all, this work is havily based on this commit; https://github.com/franciscofranco/mako/commit/48e00743741efa77964781465baf35b3641ec98d
Also thanks to @Quarx2k for giving me the right device-tree changes.

This commit adds a undervolting interface for the moto g. Normally the kernel
would set the right voltages at boot (during some sort of configuration phase).
Although AVS works as it should, we can still undervolt a little bit more.
A quick dmesg | grep cpr_voltage_plan_init reveals the current voltages for the cpu.
On nearly all Moto Gs this is set to the lowest possible value (1140000 uV).

Starting with the lowest value for the voltage;
echo 1140 1140 1140 1140 1140 1140 1140 > /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table

I set the default values to 1140, 1150, 1280 which seem to be the same as before
AVS kicks in. I am sure we can take the AVS-process into account and set the
correct voltages for each frequency and device during boot with this interface.
For now i am very happy with the results so far.

Signed-off-by: Blechd0se <alex.christ@hotmail.de>

Conflicts:
	arch/arm/mach-msm/Kconfig
	arch/arm/mach-msm/acpuclock-8226.c

Signed-off-by: Blechd0se <alex.christ@hotmail.de>

Conflicts:
	arch/arm/boot/dts/msm8226.dtsi