mmc: trace single-block reads and writes as well

mmc: trace single-block reads and writes as well

In addition to multi-block ones.

Change-Id: Ie67fa95e362affc7c22ee72cae39fc6692f109f7
Signed-off-by: Iliyan Malchev <malchev@google.com>
oom: remove oom_disable_count

oom: remove oom_disable_count

This removes mm->oom_disable_count entirely since it's unnecessary and
currently buggy.  The counter was intended to be per-process but it's
currently decremented in the exit path for each thread that exits, causing
it to underflow.

The count was originally intended to prevent oom killing threads that
share memory with threads that cannot be killed since it doesn't lead to
future memory freeing.  The counter could be fixed to represent all
threads sharing the same mm, but it's better to remove the count since:

 - it is possible that the OOM_DISABLE thread sharing memory with the
   victim is waiting on that thread to exit and will actually cause
   future memory freeing, and

 - there is no guarantee that a thread is disabled from oom killing just
   because another thread sharing its mm is oom disabled.

Signed-off-by: David Rientjes <rientjes@google.com>
Reported-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Cc: Ying Han <yinghan@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>
Change-Id: If5667b6eb784b0503179f2f4e9aef0b5ecbdb368
oom: do not kill tasks with oom_score_adj OOM_SCORE_ADJ_MIN

oom: do not kill tasks with oom_score_adj OOM_SCORE_ADJ_MIN

Commit c9f01245 ("oom: remove oom_disable_count") has removed the
oom_disable_count counter which has been used for early break out from
oom_badness so we could never select a task with oom_score_adj set to
OOM_SCORE_ADJ_MIN (oom disabled).

Now that the counter is gone we are always going through heuristics
calculation and we always return a non zero positive value.  This means
that we can end up killing a task with OOM disabled because it is
indistinguishable from regular tasks with 1% resp.  CAP_SYS_ADMIN tasks
with 3% usage of memory or tasks with oom_score_adj set but OOM enabled.

Let's break out early if the task should have OOM disabled.

Signed-off-by: Michal Hocko <mhocko@suse.cz>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Ying Han <yinghan@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Change-Id: I73c8ed52c49069ee98cc08c7c9e06327dd11455b
cpufreq: sysfs knobs for disabling hotplug during UI interaction

cpufreq: sysfs knobs for disabling hotplug during UI interaction

Provide the following sysfs knobs:
	/sys/devices/system/cpu/cpufreq/interactive
		core_lock_period, default 200000ns
		core_lock_count, default 0 (num_online_cpus)

Sysfs file core_lock_period controls the amount of time, in nanoseconds, to
hold some cores online.  It defaults to 200ms.  The number of cores to keep
online for that duration is controlled by core_lock_count, which defaults to 0.
When 0, we simply force num_online_cpus() to stay online; if greater than 0, we
force max(core_lock_count, num_online_cpus()) to stay online.

Note that you can write any value to core_lock_count, but it will get capped to
the number of cores actually available.

Change-Id: I6937e433c8343f8205e305d9da1a62f284b47f4f
Signed-off-by: Iliyan Malchev <malchev@google.com>