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>
drivers: cpufreq: ondemand: add touchpoke & 2phase.

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>

Conflicts:
	drivers/cpufreq/cpufreq_ondemand.c
cpufreq: ondemand: limit 2phase freq to max lpcpu if only one cpu is online

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>
cpufreq: ondemand: 2phase: double the counter if we have limited the freq

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>
cpufreq: ondemand: 2phase: check for lp instead of online cpus

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>
cpufreq: ondemand: update comments

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>
cpufreq: ondemand: add earlysuspend/lateresume drivers

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>

Conflicts:

	drivers/cpufreq/cpufreq_ondemand.c
cpufreq: ondemand: set 2phase to 204Mhz if lp && screen off

Since we are limited to 475Mhz either way while our screen is
offline reduce the 2phase freq to 204Mhz to avoid ramping to max.

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>
[CPUFREQ] CPUfreq ondemand: update sampling rate without waiting for next sampling

When a new sampling rate is shorter than the current one, (e.g., 1 sec
--> 10 ms) regardless how short the new one is, the current ondemand
mechanism wait for the previously set timer to be expired.

For example, if the user has just expressed that the sampling rate
should be 10 ms from now and the previous was 1000 ms, the new rate may
become effective 999 ms later, which could be not acceptable for the
user if the user has intended to speed up sampling because the system is
expected to react to CPU load fluctuation quickly from __now__.

In order to address this issue, we need to cancel the previously set
timer (schedule_delayed_work) and reset the timer if resetting timer is
expected to trigger the delayed_work ealier.

Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Dave Jones <davej@redhat.com>
cpufreq: ondemand: adjust default parameters

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>
cpufreq: ondemand: add power_save_bias screen off override

This will set power_save_bias to 200 on screen off and
restore it's original value once the screen comes back on
again.

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>

Conflicts:

	drivers/cpufreq/cpufreq_ondemand.c
cpu-tegra: fix compiling without BEST_TRADE_HOTPLUG enabled
Patch: Complete removal of BEST_TRADE_HOTPLUG, TEGRA_INTERACTIVE_GOV_ON_EARLY_SUSPEND, and TEGRA_CONSERVATIVE_GOV_ON_EARLY_SUSPEND

Conflicts:
	arch/arm/configs/kozmik_defconfig
cpufreq: ondemand: increase 2phase screen off lp frequency

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>
mach-tegra: board-endeavoru/td: add ondemand two phase init
mach-tegra: cpu: several changes, see commit msg
'mach-tegra: cpu: several changes, see commit msg
cpufreq: ondemand: remove fixed idle frequency. Always set to lpcore max clock

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>

Conflicts:
	drivers/cpufreq/cpufreq_ondemand.c
mach-tegra: cpu-tegra: set default min clock on boot. (102)

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>
cpufreq: ondemand: tweak up threshold

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>