Add Smartass V2 governor

Change-Id: Iad3a41afdb83c3ad20e2bb97ce6fc7765bdb39c6
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>
Split interactive governor in two

Save a copy of the actual interactive as interactive2 and revert it to
an initial point to start a new developing line.

Also, activate LGE_IDLE_MAX_FREQ for in-built X behaviour.

Conflicts:

	arch/arm/configs/black_diana3_v0_defconfig
	drivers/cpufreq/cpufreq_interactive.c

Change-Id: I26d39d55214c8b321b8310f8e2e45f16cd5f0d2d
Range of improvements to interactive

cpufreq: interactive: handle speed up and down in the realtime task
cpufreq: interactive: remove input_boost handling
cpufreq: interactive: always limit initial speed bump to hispeed
cpufreq: interactive: run at fraction of hispeed_freq when load is low
cpufreq: interactive: pin timers to associated CPU
cpufreq: interactive: use deferrable timer by default
cpufreq: interactive: kick timer on idle exit past expiry
cpufreq: interactive: trace actual speed in target speed decisions
cpufreq: interactive: change speed according to current speed and target load
cpufreq: interactive: apply above_hispeed_delay to each step above hispeed
cpufreq: interactive: allow arbitrary speed / target load mappings
cpufreq: interactive: remove load since last speed change
cpufreq: interactive: adjust load for changes in speed
cpufreq: interactive: specify duration of CPU speed boost pulse
cpufreq: interactive: add timer slack to limit idle at speed > min
cpufreq: interactive: fix boosting logic
cpufreq: interactive: fix racy timer stopping
cpufreq: interactive: fix race on timer restart on governor start
cpufreq: interactive: default go_hispeed_load 99%, doc updates
cpufreq: interactive: init default values at compile time
cpufreq: interactive: don't handle transition notification if not enabled
cpufreq: interactive: fix deadlock on spinlock in timer
cpufreq: interactive: fix race on governor start/stop

Change-Id: I83fa843746a3346a7ef870174935d13ac4c260db
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Swap interactive governors

Now Interactive becomes interactiveb and interactive2 becomes
interactive. The reason is that the old interactive has problems
on the first boot.

Conflicts:

	arch/arm/configs/black_diana3_v0_defconfig

Change-Id: Iec2e1708dcfcfd60dfbea96bdb7685bf16c7b645
Add LionHeart governor

Change-Id: I57aba8780851a822326fc5deaa03cc17849d845e
block: prepare I/O context code for BFQ-v5r1 for 3.0

BFQ uses struct cfq_io_context to store its per-process per-device data,
reusing the same code for cic handling of CFQ.  The code is not shared
ATM to minimize the impact of these patches.

This patch introduces a new hlist to each io_context to store all the
cic's allocated by BFQ to allow calling the right destructor on module
unload; the radix tree used for cic lookup needs to be duplicated
because it can contain dead keys inserted by a scheduler and later
retrieved by the other one.

Update the io_context exit and free paths to take care also of
the BFQ cic's.

Change the type of cfqq inside struct cfq_io_context to void *
to use it also for BFQ per-queue data.

A new bfq-specific ioprio_changed field is necessary, too, to avoid
clobbering cfq's one, so switch ioprio_changed to a bitmap, with one
element per scheduler.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>

Conflicts:

	block/Kconfig.iosched

Change-Id: I47c1196f96c5c9cd0cee293834d8f444e07153f5
Signed-off-by: Kasper Hettinga <kasper.hettinga@gmail.com>
block: cgroups, kconfig, build bits for BFQ-v5r1-3.0

Add a Kconfig option and do the related Makefile changes to compile
the BFQ I/O scheduler.  Also let the cgroups subsystem know about the
BFQ I/O controller.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>

Conflicts:

	block/Makefile

Change-Id: If47e10e1fda658ba6b75d12d150a3640fff74714
block: introduce the BFQ-v5r1 I/O sched for 3.0

Add the BFQ-v5r1 I/O scheduler to 3.0.
The general structure is borrowed from CFQ, as much code. A (bfq_)queue is
associated to each task doing I/O on a device, and each time a scheduling
decision has to be taken a queue is selected and it is served until it expires.

    - Slices are given in the service domain: tasks are assigned budgets,
      measured in number of sectors. Once got the disk, a task must
      however consume its assigned budget within a configurable maximum time
      (by default, the maximum possible value of the budgets is automatically
      computed to comply with this timeout). This allows the desired latency
      vs "throughput boosting" tradeoff to be set.

    - Budgets are scheduled according to a variant of WF2Q+, implemented
      using an augmented rb-tree to take eligibility into account while
      preserving an O(log N) overall complexity.

    - A low-latency tunable is provided; if enabled, both interactive and soft
      real-time applications are guaranteed very low latency.

    - Latency guarantees are preserved also in presence of NCQ.

    - High throughput with flash-based devices, while still preserving
      latency guarantees.

    - Useful features borrowed from CFQ: cooperating-queues merging (with
      some additional optimizations with respect to the original CFQ version),
      static fallback queue for OOM.

    - BFQ supports full hierarchical scheduling, exporting a cgroups
      interface.  Each node has a full scheduler, so each group can
      be assigned its own ioprio and an ioprio_class.

    - If the cgroups interface is used, weights can be explictly assigned,
      otherwise ioprio values are mapped to weights using the relation
      weight = IOPRIO_BE_NR - ioprio.

    - ioprio classes are served in strict priority order, i.e., lower
      priority queues are not served as long as there are higher priority
      queues.  Among queues in the same class the bandwidth is distributed
      in proportion to the weights of each queue. A very thin extra bandwidth
      is however guaranteed to the Idle class, to prevent it from starving.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
Changes to allow BFQ compilation

Change-Id: I701d19f248326fda6389dea98dd6451f2f8e94c8
Bump version to 1.3

Change-Id: I553d6a8795d7c883f8f3096b513f840683c4153a