add temp build script
add clean script
branding
Kill off all logspam

commit 6dfc118f16e3c84b21507483d71e755d8959f818
Author: Varun Chitre <varun.chitre15@gmail.com>
Date:   Sat Sep 27 03:24:57 2014 -0400

    Cleanup some code

commit 113b4b7a91806e68aeec050ba59ecd6441d8ea05
Author: Varun Chitre <varun.chitre15@gmail.com>
Date:   Fri Sep 26 12:41:37 2014 -0400

    remove more logspam - these are heights of logspam

    these are not debugging builds, these are user builds

commit 5c78a4c1f04a5f08aa20ad23ac65d8a80de56d21
Author: Varun Chitre <varun.chitre15@gmail.com>
Date:   Fri Sep 26 12:34:24 2014 -0400

    there dies more logspam

commit ffdd6243c5754c2e1dff43fdc646a8562b022555
Author: Varun Chitre <varun.chitre15@gmail.com>
Date:   Fri Sep 26 12:29:34 2014 -0400

    God!! so much log spam!

    Kill all of it

commit 2c4ec2f337b3c1c03e6219e12dace82429be2175
Author: Varun Chitre <varun.chitre15@gmail.com>
Date:   Fri Sep 26 12:25:03 2014 -0400

    just stfu already
More logspam here
fs: dynamic fsync control

Signed-off-by: Varun Chitre <varun.chitre15@gmail.com>
NOATIME and NODIRATIME by default
Disabled GFS and enabled ARCH_POWER
Optimized SLUB
Asynchronous I/O latency to a solid-state disk greatly increased
random: entropy tweaks are all the rage nowadays

use nonblocking for all.  Read this web page:
http://lwn.net/Articles/489734/ - WIP

commit d19e78c01870bc32e40862b50881bb30fe046933 1 parent 709ec23
maxl authored a day ago voku committed in 12 hours
mm: Dynamic management of dirty page writebacks

This feature allows to have two different intervals for dirty page
writebacks and to dynamically manage them when the system has been
resumed (it's active) or when has been suspended.

Three new procfs parameters are exposed inside /proc/sys/vm path:
- "dynamic_dirty_writeback" is the activation status of this feature,
  set 1 to enable it, set 0 to disable it and use the standard behaviour
- "dirty_writeback_active_centisecs" is the interval for the dirty page
  writebacks when the system is active (screen on)
- "dirty_writeback_suspend_centisecs" is the interval for the dirty page
  writebacks when the system is suspended (screen off)

This feature is in part inspired on Francisco Franco's patch:
https://github.com/franciscofranco/mako/commit/34d79548cf16b69c7d0154836018e7f258a22947

Signed-off-by: Cristoforo Cataldo <cristoforo.cataldo@gmail.com>

Conflicts:
	mm/Kconfig

Conflicts:
	mm/Kconfig
not a static function
block: SIO

Conflicts:
	block/Makefile
Lock initial TCP window size to 64k (Improves network ping and output)
Optimize apply_slack() for size and speed -- http://lkml.indiana.edu/hypermail/linux/kernel/1201.3/03172.html
kernel:sched: LOAD_FREQ (4*HZ+61) avoids loadavg Moire

LOAD_FREQ is (5*HZ+1) to avoid high load average when idle:
http://kerneltrap.org/mailarchive/linux-kernel/2007/10/3/328568

I suggest (4*HZ+61) for a better distribution.

With some seconds based load (like SSL heartbeats)
and LOAD_FREQ at (5*HZ+1) I see Moire patterns like inverse sawtooth,
since 2 or 3 probes hit the jobs (load increases quickly),
followed by several probes missing it.

A 4.61 sec interval gives optimal distribution over when within a
second a probe is taken, as .61 is close to golden ratio phi 1.618...
(test in http://ripke.com/goldenratio.c).

12*4.61 = 55.32 secs is still close to a minute,
and 13*4.61=59.93 is even closer than the current 12*5.01=60.12
(with exponents EXP_x adjusted to a ratio of 13 instead of 12).
arm: Allow SCHED_HRTICK on ARM

Change-Id: If2b88db830ff54ab48d9efb54f936f93c2a077e3
block: cgroups, kconfig, build bits for BFQ-v6r2 for 3.4

Update Kconfig.iosched to include kernel configuration options
for BFQ. Add a Kconfig option and do the related Makefile changes
to compile the 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/Kconfig.iosched
	block/Makefile

Conflicts:
	block/Kconfig.iosched
	block/Makefile

Conflicts:
	block/Makefile

Conflicts:
	block/Makefile
block: introduce the BFQ-v6r2 I/O sched for 3.4

Add the BFQ-v6r2 I/O scheduler to 3.4.
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 made a queue is selected and 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.

    - Also with flash-based devices, a high throughput is achieved 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 (mapped to a weight, see next point)
      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 weight 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>