bcmdhd4354: filter multicast packages while suspended [halaszk]

In some crowded WLANs, with a lot of multicast packages circulating, the device would not enter deep sleep. This will allow the device to enter deep sleep.

16Sept2014 – Adjusted from bcmdhd to bcmdhd4354 by UpInTheAir@XDA
tcp: add a sysctl to config the tcp_default_init_rwnd [Abgrall]

The default initial rwnd is hardcoded to 10.

Now we allow it to be controlled via
 /proc/sys/net/ipv4/tcp_default_init_rwnd
 which limits the values from 3 to 100

This is somewhat needed because ipv6 routes are
 autoconfigured by the kernel.

See "An Argument for Increasing TCP's Initial Congestion Window"
 in https://developers.google.com/speed/articles/tcp_initcwnd_paper.pdf

Change-Id: I386b2a9d62de0ebe05c1ebe1b4bd91b314af5c54

Signed-off-by: JP Abgrall <jpa@google.com>
ext4: add support for FIDTRIM, a best-effort ioctl for deep discard trim [Geremy Condra]

* What
This provides an interface for issuing an FITRIM which uses the
secure discard instead of just a discard.
Only the eMMC command is "secure", and not how the FS uses it:
due to the fact that the FS might reassign a region somewhere else,
the original deleted data will not be affected by the "trim" which only
handles un-used regions.
So we'll just call it "deep discard", and note that this is a
"best effort" cleanup.

* Why
Once in a while, We want to be able to cleanup most of the unused blocks
after erasing a bunch of files.
We don't want to constantly secure-discard via a mount option.

From an eMMC spec perspective, it tells the device to really get rid of
all the data for the specified blocks and not just put them back into the
pool of free ones (unlike the normal TRIM). The eMMC spec says the
secure trim handling must make sure the data (and metadata) is not available
anymore. A simple TRIM doesn't clear the data, it just puts blocks in the
free pool.
JEDEC Standard No. 84-A441
  7.6.9 Secure Erase
  7.6.10 Secure Trim

From an FS perspective, it is acceptable to leave some data behind.
 - directory entries related to deleted files
 - databases entries related to deleted files
 - small-file data stored in inode extents
 - blocks held by the FS waiting to be re-used (mitigated by sync).
 - blocks reassigned by the FS prior to FIDTRIM.

Change-Id: I676a1404a80130d93930c84898360f2e6fb2f81e
Signed-off-by: Geremy Condra <gcondra@google.com>
Signed-off-by: JP Abgrall <jpa@google.com>
ext4: Speedup WB_SYNC_ALL pass called from sync(2) [Jan Kara]

When doing filesystem wide sync, there's no need to force transaction commit (or synchronously write inode buffer) separately for each inode because ext4_sync_fs() takes care of forcing commit at the end (VFS takes care of flushing buffer cache, respectively). Most of the time this slowness doesn't manifest because previous WB_SYNC_NONE writeback doesn't leave much to write but when there are processes aggressively creating new files and several filesystems to sync, the sync slowness can be noticeable. In the following test script sync(1) takes around 6 minutes when there are two ext4 filesystems mounted on a standard SATA drive. After this patch sync takes a couple of seconds so we have about two orders of magnitude improvement.

      function run_writers
      {
        for (( i = 0; i < 10; i++ )); do
          mkdir $1/dir$i
          for (( j = 0; j < 40000; j++ )); do
            dd if=/dev/zero of=$1/dir$i/$j bs=4k count=4 &>/dev/null
          done &
        done
      }

      for dir in "$@"; do
        run_writers $dir
      done

      sleep 40
      time sync

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
CFLAG / LDFLAG Build Optimisations
bump go_highspeed_load back to 99
disable further debug options
drivers: usb: Use Android device as USB keyboard/mouse [pelya]

- 03 September 2014 ported for Samsung Galaxy Tab S SM-705 LTE by UpInTheAir@XDA

Base project: https://github.com/pelya/android-keyboard-gadget
Required app: https://play.google.com/store/apps/details?id=remote.hid.keyboard.client

Steps:
* Start ADB Debugging
* Start app
* Connect device to system via USB cable
USB KEYBOARD/MOUSE: added on/off trigger to driver. READ MORE [dorimanx]

- 03 September 2014 ported (fixing compile error) for Samsung Galaxy Tab S SM-705 LTE by UpInTheAir@XDA

When was ON by default I have seen that USB is always HID device.

And i have always received 2 connection sounds and vibrate...

It's annoying! so now all good, one alert for connection, and USB is Android Device, and when I have connect USB Keyboard or mouse or both via wireless connector (Microsoft keyboard + mouse Infra-Red) it works! Phone detect mouse + keyboard and I can use them on screen!

The on/off trigger seems not needed to use the HID and can be OFF. I have left it for future use, for compatibility if needed.
scheduler: BFQ-v7r4 for 3.4.0 [Paolo Valente]
scheduler: update BFQ-v7r4 to BFQ-v7r5 for 3.4.0 [Paolo Valente]
block: Reserve only one queue tag for sync IO if only 3 tags are available

In case a device has three tags available we still reserve two of them
for sync IO. That leaves only a single tag for async IO such as
writeback from flusher thread which results in poor performance.

Allow async IO to consume two tags in case queue has three tag availabe
to get a decent async write performance.

This patch improves streaming write performance on a machine with such disk
from ~21 MB/s to ~52 MB/s. Also postmark throughput in presence of
streaming writer improves from 8 to 12 transactions per second so sync
IO doesn't seem to be harmed in presence of heavy async writer.

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
bfq-iosched: tuning for SSD [anarkia1976]
block: squashed commits to add FIOPS I/O scheduler [Shaohua Li]

block: fiops ioscheduler core

FIOPS (Fair IOPS) ioscheduler is IOPS based ioscheduler, so only targets for drive without I/O seek. It's quite similar like CFQ, but the dispatch decision is made according to IOPS instead of slice.

The algorithm is simple. Drive has a service tree, and each task lives in the tree. The key into the tree is called vios (virtual I/O). Every request has vios, which is calculated according to its ioprio, request size and so on. Task's vios is the sum of vios of all requests it dispatches. FIOPS always selects task with minimum vios in the service tree and let the task dispatch request. The dispatched request's vios is then added to the task's vios and the task is repositioned in the sevice tree.

Unlike CFQ, FIOPS doesn't have separate sync/async queues, because with I/O less writeback, usually a task can only dispatch either sync or async requests. Bias read or write request can still be done with read/write scale.

One issue is if workload iodepth is lower than drive queue_depth, IOPS share of a task might not be strictly according to its priority, request Bias read or write request can still be done with read/write scale.

One issue is if workload iodepth is lower than drive queue_depth, IOPS share of a task might not be strictly according to its priority, request size and so on. In this case, the drive is in idle actually. Solving the problem need make drive idle, so impact performance. I believe CFQ isn't completely fair between tasks in such case too.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>

Signed-off-by: Paul Reioux <reioux@gmail.com>

Conflicts:
        block/Kconfig.iosched
        block/Makefile

block: fiops read/write request scale

read/write speed of Flash based storage usually is different. For example, in my SSD maxium thoughput of read is about 3 times faster than that of write. Add a scale to differenate read and write. Also add a tunable, so user can assign different scale for read and write.

By default, the scale is 1:1, which means the scale is a noop.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>

block: fiops sync/async scale

CFQ gives 2.5 times more share to sync workload. This matches CFQ.

Note this is different with the read/write scale. We have 3 types of requests:
1. read
2. sync write
3. write
CFQ doesn't differentiate type 1 and 2, but request cost of 1 and 2 are usually different for flash based storage. So we have both sync/async and read/write scale here.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>

block: fiops add ioprio support

Add CFQ-like ioprio support. Priority A will get 20% more share than priority A+1, which matches CFQ.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>

block: fiops preserve vios key for deep queue depth workload

If the task has running request, even it's added into service tree newly, we preserve its vios key, so it will not lost its share. This should work for task driving big queue depth. For single depth task, there is no approach to preserve its vios key.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>

block: fiops bias sync workload

If there are async requests running, delay async workload. Otherwise async workload (usually very deep iodepth) will use all queue iodepth and later sync requests will get long delayed. The idea is from CFQ.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>

block: fiops add some trace information

Add some trace information, which is helpful when I do debugging.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: add SIO I/O scheduler [Miguel Boton]
block: add ZEN I/O scheduler [Brandon Berhent]
configdump