ram_console: set CON_ANYTIME console flag

We want to ensure that we get all the console messages, even ones
that occur while the printing CPU is not yet online.

Change-Id: I1d2694d05ac9415669a92f38efdd8e71c927705b
Signed-off-by: Dima Zavin <dima@android.com>
sched/nohz: Correctly initialize 'next_balance' in 'nohz' idle balancer

The 'next_balance' field of 'nohz' idle balancer must be initialized
to jiffies. Since jiffies is initialized to negative 300 seconds the
'nohz' idle balancer does not run for the first 300s (5mins) after
bootup. If no new processes are spawed or no idle cycles happen, the
load on the cpus will remain unbalanced for that duration.

Signed-off-by: Diwakar Tundlam <dtundlam@nvidia.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1DD7BFEDD3147247B1355BEFEFE4665237994F30EF@HQMAIL04.nvidia.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>

[xqi@codeaurora.org merge into different file location in 3.0]
Change-Id: I42c41210babb0881150d28d11c2d3fce24fe3a9f
Signed-off-by: Xin Qi <xqi@codeaurora.org>
sched/nohz: Fix logic in nohz_kick_needed

Update the logic so that as long as rq->nr_running is greater than 1,
nohz_kick will be needed, regardless of whether the current CPU has
successfully competed for the first or second cpu spot

Previous logic has the corner case that if current CPU has r_running more than
1, and two other CPUs alreay hold first and econd cpu spot, but they don't
meeting kicking criterial (first cpu has nr_running 1, and second cpu doesn't
have any load), then nohz_kick will not be set correctly.

Change-Id: I30790f22df0a2e90899daa44c67757284dcca25d
Signed-off-by: Xin Qi <xqi@codeaurora.org>
sched/nohz: Fix logic in run_rebalance_domains

If triggered by nohz_balancer_kick, idle_at_tick is not updated
accordingly.  Update myself at this moment right before it is used

Change-Id: I20dd4314159e70f955ffe482160c8867c65c261e
Signed-off-by: Xin Qi <xqi@codeaurora.org>

Conflicts:
	kernel/sched_fair.c

Conflicts:

	kernel/sched_fair.c
SCHED: Fix nohz merge
Patch Final: ached: Folding nohz load accounting more accurate! + GOVS

Thanks to Charles Wang for spotting the defects in the current code:

 - If we go idle during the sample window -- after sampling, we get a
   negative bias because we can negate our own sample.

 - If we wake up during the sample window we get a positive bias
   because we push the sample to a known active period.

So rewrite the entire nohz load-avg muck once again, now adding
copious documentation to the code.

Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Reported-and-tested-by: Doug Smythies <dsmythies@xxxxxxxxx>
Reported-and-tested-by: Charles Wang <muming.wq@xxxxxxxxx>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
[PATCHv2 1/2] ached: Folding nohz load accounting more accurate
V1-->V2 Use per-cpu variable instead of cpumask to avoid lock.

After patch 453494c3d4 (ached: Fix nohz load accounting -- again!), we
can fold
the idle into calc_load_tasks_idle between the last cpu load
calculating and
calc_global_load calling. However problem still exits between the first
cpu
load calculating and the last cpu load calculating. Every time when we
do load
calculating, calc_load_tasks_idle will be added into calc_load_tasks,
even if
the idle load is caused by calculated cpus. Consider following case:
5HZ+1
| cpu0_load     cpu1    cpu2    cpu3    calc_load_tasks    tasks_idle
|    1           1       1       1
|  -->calc_load                             1                  0
|    1           1       1       1
|                    -->calc_load           2                  0
|    0           0       1       0
|                    -->calc_load           2+1-3=0            -3
|    1           1       0       1
|                            -->calc_load   1-1=0              -1
V
5HZ+11     -->calc_global_load              0                  0

actually the load should be around 3, but shows nearly 0.

This can be found in our work load. The average running processes number
is about 15, but the load only shows about 4.

We provides a solution, by taking those load not calculated cpus' idle
out from
global idle as calc_unmask_cpu_load_idle. Then when calc_load execute
on every
cpu, we only fold calc_unmask_cpu_load_idle. After this patch, case
above
should be as follow:
5HZ+1
| cpu0_load     cpu1    cpu2    cpu3   calc_load_tasks tasks_idle
unmask_idle
|    1           1       1       1
|  -->calc_load                             1              0           0
|    1           1       1       1
|              -->calc_load                 2              0           0
|    0           0       1       0
|                    -->calc_load           2+1-1=2        -3
-1
|    1           1       0       1
|                            -->calc_load   2+1=3          -2-1=-3     0
V
5HZ+11     -->calc_global_load              3              -3          0

CC: Peter Zijlstra <peterz@infradead.org>
CC: Doug Smythies <dsmythies@telus.net>
CC: Ingo Molnar <mingo@redhat.com>
CC: Tao Ma <tm@tao.ma>
CC: Sha Zhengju <handai.szj@gmail.com>
Reported-by: Sha Zhengju <handai.szj@gmail.com>
Signed-off-by: Charles Wang <muming.wq@taobao.com>

Conflicts:

	kernel/sched_idletask.c
[PATCH] Automatic update of the duration of the weight raising

To provide low latency, bfq raises the weight of the applications to be
privileged. This heuristic alone does not suffice. One of the other
additional mechanisms used by bfq is performing disk idling for
weight-raised applications. Disk idling means that, if one such
applications runs out of requests while it is being served, bfq idle
the disk and waits for a few ms for the next request of the application
to arrive.

This waiting is critical for low latency, but does not allow SSD
devices to reach maximum throughput.
For this reason, the weight-raising (and related disk-idling) duration
should be kept low. For interactive applications, this duration is
controlled by the raising_max_time sysfs parameter. We set its value,
conservatively, to 7.5 seconds.

Once applied this experimental patch things change. If raising_max_time
is set to 0 (default value), then bfq computes it automatically. In
particular, bfq adapts, heuristically, to the speed of the disk: the
higher the speed of the disk is, the lower it takes to load
applications on that disk, and hence the lower the value assigned
automatically by bfq to this parameter is. By doing so, after a new
application is started, bfq goes into 'high-thoughput for SSD' mode for
that application as soon as possible, without sacrificing latency. You
can find more detail sin the comments within the patch itself.

It is of course an heuristic, so only usage can tell us how effective
it is actually. According to our tests, it is apparently working well
(we are just using it on our PCs). This patch is for v4-3.5, but it
probably applies (almost) cleanly also to v4 for older kernel versions.
In case of problems just let us know.

https://groups.google.com/forum/?fromgroups#!topic/bfq-iosched/hPe2jFW55
Is%5B1-25%5D
sched: task_times() explosion avoidance for tasks with > 2^32 acrued ticks

If stime + utime > 2^32, and lower 32 are 0 when user calls getrusage(),
you've got a dead box.
Signed-off-by: Mike Galbraith <efault@gmx.de>
backported from Linux 3.5+ to Linux 3.0 by faux123
sched,rt: fix isolated CPUs leaving root_task_group indefinitely throttled

Speaking of old "parches" lying about, the below fixes a real problem if
you're using either 'should die' isolcpus or 'should work' cpusets to
isolate cores.

sched,rt: fix isolated CPUs leaving root_task_group indefinitely throttled

Root task group bandwidth replenishment must service all CPUs, regardless of
where the timer was last started, and regardless of the isolation mechanism,
lest 'Quoth the Raven, "Nevermore"' become rt scheduling policy.

Signed-off-by: Mike Galbraith <efault@gmx.de>
backported from Linux 3.5+ to linux 3.0 by faux123
lib/lzo: Rename lzo1x_decompress.c to lzo1x_decompress_safe.c

Rename the source file to match the function name and thereby
also make room for a possible future even slightly faster
"non-safe" decompressor version.

Signed-off-by: Markus F.X.J. Oberhumer <markus@oberhumer.com>
lib/lzo: Update LZO compression to current upstream version

This commit updates the kernel LZO code to the current upsteam version
which features a significant speed improvement - benchmarking the Calgary
and Silesia test corpora typically shows a doubled performance in
both compression and decompression on modern i386/x86_64/powerpc machines.

Signed-off-by: Markus F.X.J. Oberhumer <markus@oberhumer.com>
Proportional Rate Reduction for TCP.

This patch implements Proportional Rate Reduction (PRR) for TCP.
PRR is an algorithm that determines TCP's sending rate in fast
recovery. PRR avoids excessive window reductions and aims for
the actual congestion window size at the end of recovery to be as
close as possible to the window determined by the congestion control
algorithm. PRR also improves accuracy of the amount of data sent
during loss recovery.

The patch implements the recommended flavor of PRR called PRR-SSRB
(Proportional rate reduction with slow start reduction bound) and
replaces the existing rate halving algorithm. PRR improves upon the
existing Linux fast recovery under a number of conditions including:
  1) burst losses where the losses implicitly reduce the amount of
outstanding data (pipe) below the ssthresh value selected by the
congestion control algorithm and,
  2) losses near the end of short flows where application runs out of
data to send.

As an example, with the existing rate halving implementation a single
loss event can cause a connection carrying short Web transactions to
go into the slow start mode after the recovery. This is because during
recovery Linux pulls the congestion window down to packets_in_flight+1
on every ACK. A short Web response often runs out of new data to send
and its pipe reduces to zero by the end of recovery when all its packets
are drained from the network. Subsequent HTTP responses using the same
connection will have to slow start to raise cwnd to ssthresh. PRR on
the other hand aims for the cwnd to be as close as possible to ssthresh
by the end of recovery.

A description of PRR and a discussion of its performance can be found at
the following links:
- IETF Draft:
    http://tools.ietf.org/html/draft-mathis-tcpm-proportional-rate-reduction-01
- IETF Slides:
    http://www.ietf.org/proceedings/80/slides/tcpm-6.pdf
    http://tools.ietf.org/agenda/81/slides/tcpm-2.pdf
- Paper to appear in Internet Measurements Conference (IMC) 2011:
    Improving TCP Loss Recovery
    Nandita Dukkipati, Matt Mathis, Yuchung Cheng

Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
lib/lzo: Fixup per the last two lzo patches
block: Expose kblock_schedule_delayed_work()

This function is exported in blk-core.c to be used in other modules
but it's definition in h file is missing.

Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>