Some compiling optimizations

Change-Id: I74868d17d1cc243c102dc27ba26d600a654cbf73
Signed-off-by: Josue Rivera <prbassplayer@gmail.com>
Remove some debug info that isn't needed

Change-Id: I4bab1cb1f68c4a083ea4300b5a2e1144a3c57442
Signed-off-by: Josue Rivera <prbassplayer@gmail.com>

Conflicts:
	arch/arm/configs/slim_mako_defconfig
Disable Os flag so it uses O2

Change-Id: Ib95d2aac9dcb0816c3fd2ee7140619d1277e09f6
Signed-off-by: Josue Rivera <prbassplayer@gmail.com>

Conflicts:
	arch/arm/configs/slim_mako_defconfig
More optimizations

Change-Id: I81ac2ec92b31802faa8f0d116f3d230c48bf9e96
Signed-off-by: Josue Rivera <prbassplayer@gmail.com>
fs/sync: Make sync() satisfy many requests with one invocation

Dave Jones reported RCU stalls, overly long hrtimer interrupts, and
amazingly long NMI handlers from a trinity-induced workload involving
lots of concurrent sync() calls (https://lkml.org/lkml/2013/7/23/369).
There are any number of things that one might do to make sync() behave
better under high levels of contention, but it is also the case that
multiple concurrent sync() system calls can be satisfied by a single
sys_sync() invocation.

Given that this situation is reminiscent of rcu_barrier(), this commit
applies the rcu_barrier() approach to sys_sync().  This approach uses
a global mutex and a sequence counter.  The mutex is held across the
sync() operation, which eliminates contention between concurrent sync()
operations.  The counter is incremented at the beginning and end of
each sync() operation, so that it is odd while a sync() operation is in
progress and even otherwise, just like sequence locks.

The code that used to be in sys_sync() is now in do_sync(), and sys_sync()
now handles the concurrency.  The sys_sync() function first takes a
snapshot of the counter, then acquires the mutex, and then takes another
snapshot of the counter.  If the values of the two snapshots indicate that
a full do_sync() executed during the mutex acquisition, the sys_sync()
function releases the mutex and returns ("Our work is done!").  Otherwise,
sys_sync() increments the counter, invokes do_sync(), and increments
the counter again.

This approach allows a single call to do_sync() to satisfy an arbitrarily
large number of sync() system calls, which should eliminate issues due
to large numbers of concurrent invocations of the sync() system call.

Changes since v1 (https://lkml.org/lkml/2013/7/24/683):

o	Add a pair of memory barriers to keep the increments from
	bleeding into the do_sync() code.  (The failure probability
	is insanely low, but when you have several hundred million
	devices running Linux, you can expect several hundred instances
	of one-in-a-million failures.)

o	Actually CC some people who have experience in this area.

Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Jan Kara <jack@suse.cz>
Cc: Curt Wohlgemuth <curtw@google.com>
Cc: Jens Axboe <jaxboe@fusionio.com>
Cc: linux-fsdevel@vger.kernel.org

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

Change-Id: I6afa3f21c634320af8d92dde9e6c2d27f8862905
Signed-off-by: Josue Rivera <prbassplayer@gmail.com>
arm/Makefile: Optimize and add New arm flags

Change-Id: I95295f29917804fc64ad048e15cb94ff1ea8b0e4

Conflicts:
	arch/arm/Makefile
config: Remove unused MEDIA_TUNER option

Change-Id: I7d43ba75f9cff551200866e561932dd277272a5a
Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
core.c: Disable Software CRC check

Change-Id: Ib5135c526b3cf7ce23b52f86c15d862de9bc5ef8
AIO: Don't plug the I/O queue in do_io_submit() Asynchronous I/O latency to a solid-state disk greatly increased between the 2.6.32 and 3.0 kernels. By removing the plug from do_io_submit(), we observed a 34% improvement in the I/O latency.

Unfortunately, at this level, we don't know if the request is to
a rotating disk or not.

Change-Id: I7101df956473ed9fd5dcff18e473dd93b688a5c1
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Cc: linux-aio@kvack.org
Cc: Chris Mason <chris.mason@oracle.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
msm: Makefile: we don't need these in mako

Change-Id: Ib254ae3d57353cf3031cb6f2986517416bc7af3e
Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Enable pipe flag.

Change-Id: I24b4ff08070dad5df62f404a4ddb912739b6f8b4
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
kernel:sched: LOAD_FREQ (4*HZ+61) avoids loadavg Moire

LOAD_FREQ is (5*HZ+1) to avoid high load average when idle:
http://kerneltrap.org/mailarchive/linux-kernel/2007/10/3/328568

I suggest (4*HZ+61) for a better distribution.

With some seconds based load (like SSL heartbeats)
and LOAD_FREQ at (5*HZ+1) I see Moire patterns like inverse sawtooth,
since 2 or 3 probes hit the jobs (load increases quickly),
followed by several probes missing it.

A 4.61 sec interval gives optimal distribution over when within a
second a probe is taken, as .61 is close to golden ratio phi 1.618...
(test in http://ripke.com/goldenratio.c).

12*4.61 = 55.32 secs is still close to a minute,
and 13*4.61=59.93 is even closer than the current 12*5.01=60.12
(with exponents EXP_x adjusted to a ratio of 13 instead of 12).

Change-Id: Ibf7917f913a0c03fdaa4806f0e82dc727fe17e67
cfg80211: Fix memory leak

When a driver requests a specific regulatory domain after cfg80211 already
has one, a struct ieee80211_regdomain is leaked.

Change-Id: I74a79f3ed3177a12a5f23181a41b837f49d11ca8