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>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
defconfig: missing stuff

Signed-off-by: Dan Trifan <jimsth@gmail.com>
mm/vmscan: Add #ifdef around "WasActive page flag"

also fix a merge error @ putback_lru_page

Signed-off-by: Dan Trifan <jimsth@gmail.com>
add ondemandplus governor

Signed-off-by: Dan Trifan <jimsth@gmail.com>
ondemandplus: add and enable io_is_busy=2 option, adjust up_threshold and down_differential

Signed-off-by: Dan Trifan <jimsth@gmail.com>
ondemandplus governor: remove adaptive timer_rate logic

It is unlikely this gives any power savings and only
add some ugly code :)

Signed-off-by: Dan Trifan <jimsth@gmail.com>
defconfig: enable ondemandplus cpu gov

Signed-off-by: Dan Trifan <jimsth@gmail.com>
net: wireless: bcmdhd: Clean scan status if request is empty

Change-Id: I1c00b5a84846faf316305f57a6a74ded2288a6fd
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
OMAP4430/60: EMIF: errata: Prohibit usage of Power-Down mode

A ZQ calibration long command is issued every time on exit
from active power-down and precharge power-down modes
when EMIF is configured to use Power-down mode
(EMIF_PWR_MGMT_CTRL.REG_LP_MODE=0x4).

Due to very short periods of power-down cycles, ZQ calibration
overhead creates bandwidth issues and increases overall system
power consumption.

As result, the guideline is to not allow Power-down mode and,
therefore, to not have set the
EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field to 0x4.

TI Errata i743; IMPACTED: OMAP4430/60 all revisions

Change-Id: Ib82f28e6e0c6c046ea277b90a78dc82c1ee82417
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Vitaly Chernooky <vitaly.chernooky@ti.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
logger: Add an enable toggle for entry storage; TNX AndreiLux and Dorimanx

You can disable logging by echo-ing 0 in /sys/module/logger/parameters/log_enabled
By default the logging is enabled.

Signed-off-by: Dan Trifan <jimsth@gmail.com>
staging: android: lowmemorykiller: Management of not killable processes

This feature allows the user to define processes and system processes
white-lists filled with the preferred process names and to not be killed
by lowmemorykiller, unless it is absolutely necessary.

This feature exposes four new lowmemorykiller parameters:
- donotkill_proc, is the flag to enable / disable this feature for the
  processes chosen by the user
- donotkill_sysproc, is the flag to enable / disable this feature for the
  system processes chosen by the user
- donotkill_proc_names, is the list of process names (comma separated)
  chosen by the user to be preserved from killing
- donotkill_sysproc_names, is the list of user system process names (comma separated)
  chosen by the user to be preserved from killing

When a the lowmemorykiller needs to free ram, it will first kill the processes
not included inside the two process name lists chosen by the user.
If there are no more standard killable processes, then it will be necessary to
kill one of the processes included inside one of the two white-lists, to
prevent system hangs, slowdowns, etc.

Signed-off-by: Dan Trifan <jimsth@gmail.com>
defconfig: enable CONFIG_ANDROID_LOW_MEMORY_KILLER_DO_NOT_KILL_PROCESS

Signed-off-by: Dan Trifan <jimsth@gmail.com>
Linux v3.0.95

This is the 3.0.95 stable release.

Signed-off-by: Dan Trifan <jimsth@gmail.com>
defconfig: more autogenerated stuff

Signed-off-by: Dan Trifan <jimsth@gmail.com>
version 0.7.5 exp_bm

Signed-off-by: Dan Trifan <jimsth@gmail.com>