zram: Set initial disksize to some default value
Currently, we set initial disksize as 0, which forces
user to write some value to corresponding zram device's
sysfs node, before the device can be used. Now, we avoid
this step by providing some default size initially.

To change the disksize, user must:
 - Reset disk.
	Ex: echo 1 > /sys/block/zram0/reset
(NOTE: disksize is set to the default value after reset)
 - Set new disksize.
	Ex: echo $((256*1024*1024)) > /sys/block/zram0/disksize
Signed-off-by: Nitin Gupta <ngupta@vflare.org>
Reviewed-by: Jerome Marchand <jmarchan@redhat.com>
Staging:zram: Specify default disksize via menuconfig (in bytes)
android lowmemorykiller: Update to latest AOSP kernel

lowmemorykiller: don't unregister notifier from atomic context
lowmemorykiller: Don't wait more than one second for a process to die
lowmemorykiller: Ignore shmem pages in page-cache
android binder: update to latest AOSP kernel source

binder: Move debugging information from procfs to debugfs
binder: Use seq_file for debug interface.
staging:lowmemkiller add Fudgeswap
fudgeswap acts as follows:

If set to non zero (defualt is 512k):
	Check for the amount of SWAP_FREE space avalible
	If > 0KB is avalible:
		if fudgeswap > swapfree:
			other_file += swapfree
		else:
			other_file += fugeswap

In short: we will add in fugeswap as long as its less then the free swap

Setting this to a very large positive number will indicate swap ought
to be fully used as free (and will slow the system down)

smaller numbers will allow you to put some pressure on SWAP without
slowing the system down as much.

small negitive numbers will allow the system to be faster at the same
minfree level.

default is 512 to give a very little bit of pressure to use some swap
but this can be modified at runtime via:
/sys/module/lowmemorykiller/parameters/fugeswap
originally by ezterry, modifiedy by faux123
rcu: Accelerate grace period if last non-dynticked CPU

Currently, rcu_needs_cpu() simply checks whether the current CPU
has an outstanding RCU callback, which means that the last CPU
to go into dyntick-idle mode might wait a few ticks for the
relevant grace periods to complete.  However, if all the other
CPUs are in dyntick-idle mode, and if this CPU is in a quiescent
state (which it is for RCU-bh and RCU-sched any time that we are
considering going into dyntick-idle mode), then the grace period
is instantly complete.

This patch therefore repeatedly invokes the RCU grace-period
machinery in order to force any needed grace periods to complete
quickly.  It does so a limited number of times in order to
prevent starvation by an RCU callback function that might pass
itself to call_rcu().

However, if any CPU other than the current one is not in
dyntick-idle mode, fall back to simply checking (with fix to bug
noted by Lai Jiangshan).  Also, take advantage of last
grace-period forcing, the opportunity to do so noted by Steve
Rostedt.  And apply simplified #ifdef condition suggested by
Frederic Weisbecker.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: laijs@cn.fujitsu.com
Cc: dipankar@in.ibm.com
Cc: mathieu.desnoyers@polymtl.ca
Cc: josh@joshtriplett.org
Cc: dvhltc@us.ibm.com
Cc: niv@us.ibm.com
Cc: peterz@infradead.org
Cc: rostedt@goodmis.org
Cc: Valdis.Kletnieks@vt.edu
Cc: dhowells@redhat.com
LKML-Reference: <1266887105-1528-15-git-send-email-paulmck@linux.vnet.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
rcutiny: cleanups to tiny rcu code