readahead: make context readahead more conservative

This helps performance on moderately dense random reads on SSD.

Transaction-Per-Second numbers provided by Taobao:

		QPS	case
		-------------------------------------------------------
		7536	disable context readahead totally
w/ patch:	7129	slower size rampup and start RA on the 3rd read
		6717	slower size rampup
w/o patch:	5581	unmodified context readahead

Before, readahead will be started whenever reading page N+1 when it happen
to read N recently.  After patch, we'll only start readahead when *three*
random reads happen to access pages N, N+1, N+2.  The probability of this
happening is extremely low for pure random reads, unless they are very
dense, which actually deserves some readahead.

Also start with a smaller readahead window.  The impact to interleaved
sequential reads should be small, because for a long run stream, the the
small readahead window rampup phase is negletable.

The context readahead actually benefits clustered random reads on HDD
whose seek cost is pretty high.  However as SSD is increasingly used for
random read workloads it's better for the context readahead to concentrate
on interleaved sequential reads.

Another SSD rand read test from Miao

        # file size:        2GB
        # read IO amount: 625MB
        sysbench --test=fileio          \
                --max-requests=10000    \
                --num-threads=1         \
                --file-num=1            \
                --file-block-size=64K   \
                --file-test-mode=rndrd  \
                --file-fsync-freq=0     \
                --file-fsync-end=off    run

shows the performance of btrfs grows up from 69MB/s to 121MB/s, ext4 from
104MB/s to 121MB/s.

Change-Id: Ibe594eea2e29ec984331f915d5a96ba324b20bfe
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Tested-by: Tao Ma <tm@tao.ma>
Tested-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
CHROMIUM: tcp: Avoid merging segments on the OOO queue into a cloned SKB

TCP tries to merge socket buffers in the out-of-order queue when they
are sequential. This is generally a good thing to save memory and speed
up processing, but can lead to problems when it expands a buffer that
has previously been cloned.

We have encountered a bug with a confused/broken receive queue, that we
think might have been caused by this problem, as the smsc95xx driver
uses cloned buffers in its receive path. Thanks to edumazet for
pointing that out and suggesting this fix.

This patch makes sure that this code path only expands socket buffers
that have not been cloned and just enqueues them normally in the other
case. In upstream kernels starting with 3.5, the affected code has been
refactored into tcp_try_coalesce with commit 1402d36, which has later
been patched to fix this issue in commit 923dd34. The fix has not been
backported into the upstream 3.4 kernel.

BUG=chromium-os:35827
TEST=None

Change-Id: I2cdf09946a3cbb0cbff35b1ac09313352b8f1e94
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/37666
Reviewed-by: Eric Dumazet <edumazet@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
defconfig: Dump configs
mm: highmem_is_dirtyable = 1
audit: kiss goodbye you stupid piece of crap logging messages.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
sync: don't block the flusher thread waiting on IO

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>
writeback: fix occasional slow sync(1)

In case when system contains no dirty pages, wakeup_flusher_threads() will
submit WB_SYNC_NONE writeback for 0 pages so wb_writeback() exits
immediately without doing anything, even though there are dirty inodes in
the system.  Thus sync(1) will write all the dirty inodes from a
WB_SYNC_ALL writeback pass which is slow.

Fix the problem by using get_nr_dirty_pages() in wakeup_flusher_threads()
instead of calculating number of dirty pages manually.  That function also
takes number of dirty inodes into account.

Signed-off-by: Jan Kara <jack@suse.cz>
Reported-by: Paul Taysom <taysom@chromium.org>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mmc: core: enable async suspend

Enables the asynchronous suspend of card and class device.
This would enable both these devices to suspend in separate
respective threads, thus allowing other devices to suspend
concurrently.

CRs-fixed: 634333
Change-Id: Ic73022ef777b4fae4b1065f92cfa19da51a99634
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
mmc: sdhci-msm: enable async suspend

This is aimed to reduce the suspend time of sdhci-msm device.
The suspend of this device would be carried out in a separate
thread and other devices may suspend concurrently. This is
required since the mmc sub-system contributes to the major
chunk of suspend latency.

CRs-fixed: 634333
Change-Id: I7bdead2deacd96aec5201d82b143b07c470b3892
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
msm: kgsl: Treat 0x0 as valid GPU pagetable physical address

Iommu driver could be allocating a valid GPU pagetable at
physical address 0x0, remove assumption from GPU kernel driver
that 0x0 is invalid pagetable address.

Change-Id: I213c0fbc1d90a13bef83c7d7589ad9e5729771fd
Signed-off-by: Tarun Karra <tkarra@codeaurora.org>
writeback: fix race that cause writeback hung

There is a race between mark inode dirty and writeback thread, see the
following scenario.  In this case, writeback thread will not run though
there is dirty_io.

__mark_inode_dirty()                                          bdi_writeback_workfn()
	...                                                       	...
	spin_lock(&inode->i_lock);
	...
	if (bdi_cap_writeback_dirty(bdi)) {
	    <<< assume wb has dirty_io, so wakeup_bdi is false.
	    <<< the following inode_dirty also have wakeup_bdi false.
	    if (!wb_has_dirty_io(&bdi->wb))
		    wakeup_bdi = true;
	}
	spin_unlock(&inode->i_lock);
	                                                            <<< assume last dirty_io is removed here.
	                                                            pages_written = wb_do_writeback(wb);
	                                                            ...
	                                                            <<< work_list empty and wb has no dirty_io,
	                                                            <<< delayed_work will not be queued.
	                                                            if (!list_empty(&bdi->work_list) ||
	                                                                (wb_has_dirty_io(wb) && dirty_writeback_interval))
	                                                                queue_delayed_work(bdi_wq, &wb->dwork,
	                                                                    msecs_to_jiffies(dirty_writeback_interval * 10));
	spin_lock(&bdi->wb.list_lock);
	inode->dirtied_when = jiffies;
	<<< new dirty_io is added.
	list_move(&inode->i_wb_list, &bdi->wb.b_dirty);
	spin_unlock(&bdi->wb.list_lock);

	<<< though there is dirty_io, but wakeup_bdi is false,
	<<< so writeback thread will not be waked up and
	<<< the new dirty_io will not be flushed.
	if (wakeup_bdi)
	    bdi_wakeup_thread_delayed(bdi);

Writeback will run until there is a new flush work queued.  This may cause
a lot of dirty pages stay in memory for a long time.

Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
msm: kgsl: Fix Z180 memory leak

Decerement entry refcount, which incremented
in kgsl_sharedmem_find_region.

CRs-Fixed: 635747
Change-Id: I621ba8f8e119a9ab8ba5455b28a565e3cae2f7cd
Signed-off-by: Hareesh Gundu <hareeshg@codeaurora.org>
Revert "sync: don't block the flusher thread waiting on IO"

This reverts commit 677fd6368a7fb02e1f0d72c44d344fc708a0ff14.