block: cgroups, kconfig, build bits for BFQ-v7r5-3.16

Update Kconfig.iosched and do the related Makefile changes to include
kernel configuration options for BFQ. Also add the bfqio controller
to the cgroups subsystem.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
block: introduce the BFQ-v7r5 I/O sched for 3.16

Add the BFQ-v7r5 I/O scheduler to 3.16.
The general structure is borrowed from CFQ, as much of the code for
handling I/O contexts. Over time, several useful features have been
ported from CFQ as well (details in the changelog in README.BFQ). 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 a very low latency.

    - Latency guarantees are preserved also in the presence of NCQ.

    - Also with flash-based devices, a high throughput is achieved
      while still preserving latency guarantees.

    - BFQ features Early Queue Merge (EQM), a sort of fusion of the
      cooperating-queue-merging and the preemption mechanisms present
      in CFQ. EQM is in fact a unified mechanism that tries to get a
      sequential read pattern, and hence a high throughput, with any
      set of processes performing interleaved I/O over a contiguous
      sequence of sectors.

    - BFQ supports full hierarchical scheduling, exporting a cgroups
      interface.  Since each node has a full scheduler, each group can
      be assigned its own weight.

    - If the cgroups interface is not used, only I/O priorities can be
      assigned to processes, with ioprio values mapped to weights
      with 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>
block, bfq: add Early Queue Merge (EQM) to BFQ-v7r5 for 3.16.0

A set of processes may happen  to  perform interleaved reads, i.e.,requests
whose union would give rise to a  sequential read  pattern.  There are two
typical  cases: in the first  case,   processes  read  fixed-size chunks of
data at a fixed distance from each other, while in the second case processes
may read variable-size chunks at  variable distances. The latter case occurs
for  example with  QEMU, which  splits the  I/O generated  by the  guest into
multiple chunks,  and lets these chunks  be served by a  pool of cooperating
processes,  iteratively  assigning  the  next  chunk of  I/O  to  the first
available  process. CFQ  uses actual  queue merging  for the  first type of
rocesses, whereas it  uses preemption to get a sequential  read pattern out
of the read requests  performed by the second type of  processes. In the end
it uses  two different  mechanisms to  achieve the  same goal: boosting the
throughput with interleaved I/O.

This patch introduces  Early Queue Merge (EQM), a unified mechanism to get a
sequential  read pattern  with both  types of  processes. The  main idea is
checking newly arrived requests against the next request of the active queue
both in case of actual request insert and in case of request merge. By doing
so, both the types of processes can be handled by just merging their queues.
EQM is  then simpler and  more compact than the  pair of mechanisms used in
CFQ.

Finally, EQM  also preserves the  typical low-latency properties of BFQ, by
properly restoring the weight-raising state of  a queue when it gets back to
a non-merged state.

Signed-off-by: Mauro Andreolini <mauro.andreolini@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
block: make BFQ the default I/O scheduler

Conflicts:
	block/Kconfig.iosched
block: Switch from BFQ-v7r6 for 3.16.0 to BFQ-v7r6 for 3.17.0-rc1
block: Resync to BFQ-v7r6 for 3.17.0

Use official sources released October 19th, 2014 on BFQ site:
http://algo.ing.unimo.it/people/paolo/disk_sched/patches/3.17.0-v7r6/
net: combat buffer bloat

Set tx_queue_len to 50 (FreeBSD default) from 1000 to reduce latencies.  Set
tcp_ecn to 1 to force enable Explicit Congestion Notification.  These two
changes should make a positive impact network performance.  Possible drop in
throughput with 1 gbit and faster networks.

net: restore tcp_ecn default

Forcing ECN breaks some Cisco routers with SPI firewall enabled.
Don't hide checkpoint/restore support
Apply microcode update to CPU0 on resume

Without this patch, the boot CPU did not get its microcode updated
on resume. This bug was hidden on hyperthreading systems by the
update of the hyper-thread sibling.

https://bugzilla.kernel.org/show_bug.cgi?id=88001
hostap: restore power setting value when lost due to F/W bug

source: openwrt/patches-2.6.38/903-hostap_txpower.patch
x86: Enable monitor/mwait on Intel if BIOS hasn't already

My Intel DQ67SW (latest BIOS) disables monitor/mwait on the boot CPU
if TXT is enabled.  We're lucky that the system works at all, since
the feature is still enabled on other CPUs.

The obvious fix is to just re-enable it ourselves.

Signed-off-by: Andy Lutomirski <luto@mit.edu>

Conflicts:
    arch/x86/kernel/cpu/intel.c
x86: Enable fast strings on Intel if BIOS hasn't already

Intel SDM volume 3A, 8.4.2 says:

  Software can disable fast-string operation by clearing the
  fast-string-enable bit (bit 0) of IA32_MISC_ENABLE MSR.
  However, Intel recomments that system software always enable
  fast-string operation.

The Intel DQ67SW board (with latest BIOS) disables fast string
operations if TXT is enabled.  A Lenovo X220 disables it regardless
of TXT setting.  I doubt I'm the only person with a dumb BIOS like
this.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>

Conflicts:
	arch/x86/kernel/cpu/intel.c
Skip looking for ioapic overrides when ioapics are not present

Avinash Kurup <kurup.avinash@gmail.com> writes:

> Hi Eric,
>     I get the following errors while booting into 2.6.35-rc1. I did not
> get these in 2.6.34 . The computer however boots and works fine, So its not
> serious but the following errors are displayed in dmesg.
>
> [    0.089969] ERROR: Unable to locate IOAPIC for GSI 13
> [    0.090556] ERROR: Unable to locate IOAPIC for GSI 8
> [    0.091104] ERROR: Unable to locate IOAPIC for GSI 12
> [    0.091375] ERROR: Unable to locate IOAPIC for GSI 1
> [    0.093195] ERROR: Unable to locate IOAPIC for GSI 4
> [    0.094342] ERROR: Unable to locate IOAPIC for GSI 10
> [    0.096335] ERROR: Unable to locate IOAPIC for GSI 6

The new warning originates from acpi_get_override_irq, which I changed to
use helper functions that warn when they fail.

When IOAPICs and ACPI are enabled in a kernel and run on ACPI hardware
that doesn't use the ioapics the pnp acpi code calls this function,
looking for ACPI irq overrides.  ACPI irq overrides exist only in the
ioapic case so this function will never succeed.  So make the function
fail fast so we don't call into help functions that legitimately
complain when they fail.

Tested-by: Avinash Kurup <kurup.avinash@gmail.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
[bwh: Add config condition]
UBUNTU: SAUCE: (no-up) trace: add trace events for open(), exec() and uselib() (for v3.7+)

BugLink: http://bugs.launchpad.net/bugs/462111

This patch uses TRACE_EVENT to add tracepoints for the open(),
exec() and uselib() syscalls so that ureadahead can cheaply trace
the boot sequence to determine what to read to speed up the next.

It's not upstream because it will need to be rebased onto the syscall
trace events whenever that gets merged, and is a stop-gap.

[apw@canonical.com: updated for v3.7 and later.]
BugLink: http://bugs.launchpad.net/bugs/1085766
Signed-off-by: Scott James Remnant <scott@ubuntu.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

Conflicts:

	fs/open.c

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
fix open_exec trace
net: allow TCP YeAH configuration as default congestion control
fs: merge latest aufs for 3.17

git://git.code.sf.net/p/aufs/aufs3-linux
fs: merge aufs3-standalone patch for module support for aufs3
fs: allow module support for aufs3
Add layer7 netfilter 2.22

Source: https://dev.openwrt.org/browser/trunk/target/linux/generic

600-netfilter_layer7_2.22.patch
601-netfilter_layer7_pktmatch.patch
602-netfilter_layer7_match.patch
603-netfilter_layer7_2.6.36_fix.patch

Conflicts:
	include/uapi/linux/netfilter/Kbuild
	net/netfilter/Kconfig
	net/netfilter/nf_conntrack_core.c