ramdisk: Re-configure interactive governor

Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
ramdisk: Enable fast charge AC and notify on migrate

Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
ghost: Set max CPUs to 2

Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
msm: rq_stats: update related_cpus in the cpu_load runtime

"related_cpu" indicates the list of CPUs that need some
sort of frequency coordination, whether software or hardware.
ex:- if all cpus shares the same clock, all 4 cpus belongs to
related_cpus.

cpufreq driver updates the related_cpus during hotplug offline/online
events. Hence update related_cpus for all cpus during hotplug notifier.

CRs-fixed: 548631
Change-Id: I6543ddaeebf73d18334066b090ee7c4a72466e4a
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
msm: msm_rq_stats: remove is_smp() API

is_smp() API is unavailable on few target codes.
Until this API is defined use CONFIG_SMP to know
whether target supports SPM are not.

CRs-fixed: 579034
Change-Id: I5bd5c208b18aae27d7f36e77e9d5b38639c2c00e
Signed-off-by: Murali Nalajala <mnalajal@codeaurora.org>
msm: rq_stats: Use cpufreq API to get the current frequency

Since the acpuclock APIs are deprecated, use the cpufreq to
get the current frequency of CPUs to calculate the cpu
normalized load value.

Change-Id: I6e381d584d6725ef964bad86c835d44f3046e9c3
Signed-off-by: Archana Sathyakumar <asathyak@codeaurora.org>
msm: rq_stats: Fix wrong usage of cpufreq_quick_get()

cpufreq_quick_get() returns frequency in KHz, which is exactly what
cur_freq expect. Remove the wrong multiplication.

CRs-fixed: 645518
Change-Id: Ia8b080a188023964f5eee77c8586828097d11ad4
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>

Conflicts:
	arch/arm/mach-msm/msm_rq_stats.c
soc: qcom: rq_stats: remove the redundant iowait check

Iowait_time check is redundant and it would lead to heavy load
due to miscaluculation of idle time. Hence remove this check
as iowait will considered based on io_busy flag.

Change-Id: I4dd9f9c79205eca588daea8cc0fe892394a83391
CRs-fixed: 662052
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
[zwliew: Backported to previous RQ stat driver in MSM]
Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>

Conflicts:
	arch/arm/mach-msm/msm_rq_stats.c
soc: qcom: rq_stats: Pass correct cpu id to update_average_load function

Pass correct cpu number to update_average_load function
from cpufreq_transition_handler function. Also avoid div by zero
condition in update_average_load function.

CRs-Fixed: 708310
Change-Id: I4ec3e54b92c760ac5fa910542524fdfe919f55e9
Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
[zwliew: Backport to msm-3.4]
Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>

Conflicts:
	arch/arm/mach-msm/msm_rq_stats.c
[SCSI] Remove scsi_wait_scan module

scsi_wait_scan was introduced with asynchronous host scanning as a hack
for distributions that weren't using proper udev based wait for root to
appear in their initramfs scripts.  In 2.6.30 Commit

c751085943362143f84346d274e0011419c84202
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Sun Apr 12 20:06:56 2009 +0200

    PM/Hibernate: Wait for SCSI devices scan to complete during resume

Actually broke scsi_wait_scan because it renders
scsi_complete_async_scans() a nop for modular SCSI if you include
scsi_scans.h (which this module does).

The lack of bug reports is sufficient proof that this module is no
longer used.

Cc: Jeff Mahoney <jeffm@suse.de>
Cc: Dave Jones <davej@redhat.com>
Cc: maximilian attems <max@stro.at>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>

Conflicts:
	drivers/scsi/scsi_wait_scan.c
ARM: 8160/1: drop warning about return_address not using unwind tables

The warning was introduced in 2009 (commit 4bf1fa5a34aa ([ARM] 5613/1:
implement CALLER_ADDRESSx)). The only "problem" here is that
CALLER_ADDRESSx for x > 1 returns NULL which doesn't do much harm.

The drawback of implementing a fix (i.e. use unwind tables to implement CALLER_ADDRESSx) is that much of the unwinder code would need to be marked as not
traceable.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Conflicts:
	arch/arm/kernel/return_address.c
readahead: bump up the default readahead size

Use 512kb max readahead size, and 32kb min readahead size.

The former helps io performance for common workloads.
The latter will be used in the thrashing safe context readahead.

-- Rationals on the 512kb size --

I believe it yields more I/O throughput without noticeably increasing
I/O latency for today's HDD.

For example, for a 100MB/s and 8ms access time HDD, its random IO or
highly concurrent sequential IO would in theory be:

io_size KB  access_time  transfer_time  io_latency   util%   throughput KB/s
4           8             0.04           8.04        0.49%    497.57
8           8             0.08           8.08        0.97%    990.33
16          8             0.16           8.16        1.92%   1961.69
32          8             0.31           8.31        3.76%   3849.62
64          8             0.62           8.62        7.25%   7420.29
128         8             1.25           9.25       13.51%  13837.84
256         8             2.50          10.50       23.81%  24380.95
512         8             5.00          13.00       38.46%  39384.62
1024        8            10.00          18.00       55.56%  56888.89
2048        8            20.00          28.00       71.43%  73142.86
4096        8            40.00          48.00       83.33%  85333.33

The 128KB => 512KB readahead size boosts IO throughput from ~13MB/s to
~39MB/s, while merely increases (minimal) IO latency from 9.25ms to 13ms.

As for SSD, I find that Intel X25-M SSD desires large readahead size
even for sequential reads:

	rasize	1st run		2nd run
	----------------------------------
	  4k	123 MB/s	122 MB/s
	 16k  	153 MB/s	153 MB/s
	 32k	161 MB/s	162 MB/s
	 64k	167 MB/s	168 MB/s
	128k	197 MB/s	197 MB/s
	256k	217 MB/s	217 MB/s
	512k	238 MB/s	234 MB/s
	  1M	251 MB/s	248 MB/s
	  2M	259 MB/s	257 MB/s
   	  4M	269 MB/s	264 MB/s
	  8M	266 MB/s	266 MB/s
The two other impacts of an enlarged readahead size are

- memory footprint (caused by readahead miss)
	Sequential readahead hit ratio is pretty high regardless of max
	readahead size; the extra memory footprint is mainly caused by
	enlarged mmap read-around.
	I measured my desktop:
	- under Xwindow:
		128KB readahead hit ratio = 143MB/230MB = 62%
		512KB readahead hit ratio = 138MB/248MB = 55%
		  1MB readahead hit ratio = 130MB/253MB = 51%
	- under console: (seems more stable than the Xwindow data)
		128KB readahead hit ratio = 30MB/56MB   = 53%
		  1MB readahead hit ratio = 30MB/59MB   = 51%
	So the impact to memory footprint looks acceptable.

- readahead thrashing
	It will now cost 1MB readahead buffer per stream.  Memory tight
	systems typically do not run multiple streams; but if they do
	so, it should help I/O performance as long as we can avoid
	thrashing, which can be achieved with the following patches.

-- Benchmarks by Vivek Goyal --

I have got two paths to the HP EVA and got multipath device setup(dm-3).
I run increasing number of sequential readers. File system is ext3 and
filesize is 1G.
I have run the tests 3 times (3sets) and taken the average of it.

Workload=bsr      iosched=cfq     Filesz=1G   bs=32K
======================================================================
                    2.6.33-rc5                2.6.33-rc5-readahead
job   Set NR  ReadBW(KB/s)   MaxClat(us)    ReadBW(KB/s)   MaxClat(us)
---   --- --  ------------   -----------    ------------   -----------
bsr   3   1   141768         130965         190302         97937.3
bsr   3   2   131979         135402         185636         223286
bsr   3   4   132351         420733         185986         363658
bsr   3   8   133152         455434         184352         428478
bsr   3   16  130316         674499         185646         594311
I ran same test on a different piece of hardware. There are few SATA disks
(5-6) in striped configuration behind a hardware RAID controller.

Workload=bsr      iosched=cfq     Filesz=1G   bs=32K
======================================================================
                    2.6.33-rc5                2.6.33-rc5-readahead
job   Set NR  ReadBW(KB/s)   MaxClat(us)    ReadBW(KB/s)   MaxClat(us)
---   --- --  ------------   -----------    ------------   -----------
bsr   3   1   147569         14369.7        160191         22752
bsr   3   2   124716         243932         149343         184698
bsr   3   4   123451         327665         147183         430875
bsr   3   8   122486         455102         144568         484045
bsr   3   16  117645         1.03957e+06    137485         1.06257e+06
Tested-by: Vivek Goyal <vgoyal@redhat.com>
CC: Jens Axboe <jens.axboe@oracle.com>
CC: Chris Mason <chris.mason@oracle.com>
CC: Peter Zijlstra <a.p.zijlstra@chello.nl>
CC: Martin Schwidefsky <schwidefsky@de.ibm.com>
CC: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
USB: gadget: qdss: Fix strncmp length usage

Using a newer GCC we get the following warnings:

drivers/usb/gadget/f_qdss.c: In function 'qdss_bind_config':
drivers/usb/gadget/f_qdss.c:598: warning: argument to 'sizeof' in
'strncmp' call is the same expression as the second source; did you mean
to provide an explicit length? [-Wsizeof-pointer-memaccess]

drivers/usb/gadget/f_qdss.c: In function 'usb_qdss_open':
drivers/usb/gadget/f_qdss.c:760: warning: argument to 'sizeof' in
'strncmp' call is the same expression as the second source; did you mean
to provide an explicit length? [-Wsizeof-pointer-memaccess]

These look to be due to using sizeof(ch->name) which is a pointer, use
a simple strcmp instead.

Change-Id: I09e09a18ffb3361fc351b177ed3a35432d9ed933
Signed-off-by: Kumar Gala <galak@codeaurora.org>
Bluetooth: Remove unused hci_le_ltk_reply()

In this API, we were using sizeof operator for an array
given as function argument, which is invalid.
However this API is not used anywhere.

Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Signed-off-by: Gustavo Padovan <gustavo@padovan.org>
block/partitions: optimize memory allocation in check_partition()

Currently, sizeof(struct parsed_partitions) may be 64KB in 32bit arch, so
it is easy to trigger page allocation failure by check_partition,
especially in hotplug block device situation(such as, USB mass storage,
MMC card, ...), and Felipe Balbi has observed the failure.

This patch does below optimizations on the allocation of struct
parsed_partitions to try to address the issue:

- make parsed_partitions.parts as pointer so that the pointed memory can
  fit in 32KB buffer, then approximate 32KB memory can be saved

- vmalloc the buffer pointed by parsed_partitions.parts because 32KB is
  still a bit big for kmalloc

- given that many devices have the partition count limit, so only
  allocate disk_max_parts() partitions instead of 256 partitions always

Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reported-by: Felipe Balbi <balbi@ti.com>
Cc: Jens Axboe <axboe@kernel.dk>
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
sched: Set MC (multi-core) sched domain's busy_factor attribute to 1

busy_factor attribute of a scheduler domain causes busy CPUs (CPUs
that are not idle) to load balance less frequently in that domain,
which could impact performance by increasing scheduling latency for
tasks.

As an example, consider MC scheduler domain's attribute values of
max_interval = 4ms and busy_factor = 64. Further consider
max_load_balance_interval = 100 (HZ/10). In this case, a non-idle CPU
could put off load balance check in MC domain by 100ms. This
effectively means that a CPU running a single task in its queue could
fail to notice increased load on another CPU (that is in same MC
domain) for upto 100ms, before picking up load from the overloaded
CPU. Needless to say, this leads to increased scheduling latency for
tasks, affecting performance adversely.

By setting MC domain's busy_factor value to 1, we limit maximum
interval that busy CPU can put off load balance checks to 4ms
(effectively 10ms, given HZ value of 100).

Change-Id: Id45869d06f5556ea8eec602b65c2ffd2143fe060
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
CPU hotplug, writeback: Don't call writeback_set_ratelimit() too often during hotplug

The CPU hotplug callback related to writeback calls writeback_set_ratelimit()
during every state change in the hotplug sequence. This is unnecessary
since num_online_cpus() changes only once during the entire hotplug operation.

So invoke the function only once per hotplug, thereby avoiding the
unnecessary repetition of those costly calculations.

Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.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>
softirq: reduce latencies

In various network workloads, __do_softirq() latencies can be up
to 20 ms if HZ=1000, and 200 ms if HZ=100.

This is because we iterate 10 times in the softirq dispatcher,
and some actions can consume a lot of cycles.

This patch changes the fallback to ksoftirqd condition to :

- A time limit of 2 ms.
- need_resched() being set on current task

When one of this condition is met, we wakeup ksoftirqd for further
softirq processing if we still have pending softirqs.

Using need_resched() as the only condition can trigger RCU stalls,
as we can keep BH disabled for too long.

I ran several benchmarks and got no significant difference in
throughput, but a very significant reduction of latencies (one order
of magnitude) :

In following bench, 200 antagonist "netperf -t TCP_RR" are started in
background, using all available cpus.

Then we start one "netperf -t TCP_RR", bound to the cpu handling the NIC
IRQ (hard+soft)

Before patch :

# netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
RT_LATENCY=550110.424
MIN_LATENCY=146858
MAX_LATENCY=997109
P50_LATENCY=305000
P90_LATENCY=550000
P99_LATENCY=710000
MEAN_LATENCY=376989.12
STDDEV_LATENCY=184046.92

After patch :

# netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
RT_LATENCY=40545.492
MIN_LATENCY=9834
MAX_LATENCY=78366
P50_LATENCY=33583
P90_LATENCY=59000
P99_LATENCY=69000
MEAN_LATENCY=38364.67
STDDEV_LATENCY=12865.26

Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: David Miller <davem@davemloft.net>
Cc: Tom Herbert <therbert@google.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>