gpu: kgsl: Adjust max power level
acpuclock-8064: Adjust L2 cache
fs: sync: Delete fsync (Dynamic fsync alredy added)

It must be conflict with dynamic fsync
sync: don't block the flusher thread waiting on IO - From MikeEx kernel_msm

When sync does it's WB_SYNC_ALL writeback, it issues data Io and
then immediately waits for IO completion. This is done in the
context of the flusher thread, and hence completely ties up the
flusher thread for the backing device until all the dirty inodes
have been synced. On filesystems that are dirtying inodes constantly
and quickly, this means the flusher thread can be tied up for
minutes per sync call and hence badly affect system level write IO
performance as the page cache cannot be cleaned quickly.

We already have a wait loop for IO completion for sync(2), so cut
this out of the flusher thread and delegate it to wait_sb_inodes().
Hence we can do rapid IO submission, and then wait for it all to
complete.

Effect of sync on fsmark before the patch:

FSUse%        Count         Size    Files/sec     App Overhead
.....
0       640000         4096      35154.6          1026984
0       720000         4096      36740.3          1023844
0       800000         4096      36184.6           916599
0       880000         4096       1282.7          1054367
0       960000         4096       3951.3           918773
0      1040000         4096      40646.2           996448
0      1120000         4096      43610.1           895647
0      1200000         4096      40333.1           921048

And a single sync pass took:

real    0m52.407s
user    0m0.000s
sys     0m0.090s

After the patch, there is no impact on fsmark results, and each
individual sync(2) operation run concurrently with the same fsmark
workload takes roughly 7s:

real    0m6.930s
user    0m0.000s
sys     0m0.039s

IOWs, sync is 7-8x faster on a busy filesystem and does not have an
adverse impact on ongoing async data write operations.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

https://github.com/MikeEx/kernel_msm/commit/d4797348c70dd90fae6b11d26bdc62b1c035d0bc
Add MSM_SLEEPER mod (max screen off frequency) - From MikeEx kernel_msm

flar2 authored on 15 Feb

https://github.com/MikeEx/kernel_msm/commit/610f5d01b690aba0e7ceb093a9d3ec8c51fcdbac
drivers: input: 2w: cleaned s2w_s2sonly unused external integer - From MikeEx kernel_msm

anarkia1976 authored on 3 Dec 2013

https://github.com/MikeEx/kernel_msm/commit/4f037818d29efb1d1408198281dd9b018dde8624
net-fixes: flow_dissector: prevent an infinite loop (CVE-2013-4348) - From MikeEx kernel_msm

Jason Wang found that a malicious packet could make skb_flow_dissect()
loop forever. We must check that IP header has a valid ihl to avoid
this loop. It involves IPIP encapsulation and ihl = 0 to trigger.

Given this bug is critical, I cooked a patch before having
a fix in upstream kernel.

Tested:

Compiled/booted
Ran some tests on bnx2x and explicitely disabled hardware provided
rxhash
ethtool -K eth1 rxhash off
ethtool -K eth2 rxhash off

Google-Bug-Id: 11465355
Effort: net-fixes
Change-Id: I813e4dc48cecb05f8edfa218304e1f13fd764323
Signed-off-by: Ed Tam <etam@google.com>

Eric Dumazet authored on 1 Nov 2013

https://github.com/MikeEx/kernel_msm/commit/9f0f5a8053c25d885790bb89dee0aef1536a46c6