cpufreq: interactive: hopefully last tunables adjustments

Change-Id: Ia583b10394abd80149ef7a46f8e27a3616705229
Signed-off-by: Blechd0se <alex.christ@hotmail.de>
fs: disable dynamic fsync

Some users reported data loss in some circumstances.
I guess we should enable fsync in any case, this
might decrease perfomance noticeable, but at least
we have data integrity.

Change-Id: Ib6c31d43d69b31f55438d19e4a52b0eb138dc589
Signed-off-by: Blechd0se <alex.christ@hotmail.de>
mm: vmscan: fix possible deadlock

In some cases its possible that shrink_slab() tries to shrink negative objects of ashmem:
shrink_slab: ashmem_shrink+0x0/0xf8 negative objects to delete nr=-2147299715

This patch should fix it, not only for ashmem, but for all
who call shrink_slab.

Change-Id: Iebb494dff3b72120cc1c4e0852240ff7767d953a
Signed-off-by: Blechd0se <alex.christ@hotmail.de>
cpufreq: interactive: cleanup printks

For (nearly) realtime frequencies in kmsg-output, revert
this patch.

Change-Id: I14397390d8609f96add4bfa7fc801a9a2fa21d03
Signed-off-by: Blechd0se <alex.christ@hotmail.de>
misc: enable fsync

forgot this on the previous commit.

Change-Id: I9a21d88406415aa0236bbf7332f3c4df8cf412a4
Signed-off-by: Blechd0se <alex.christ@hotmail.de>
failslab: add ability to filter slab caches

This patch allow to inject faults only for specific slabs.
In order to preserve default behavior cache filter is off by
default (all caches are faulty).

One may define specific set of slabs like this:
# mark skbuff_head_cache as faulty
echo 1 > /sys/kernel/slab/skbuff_head_cache/failslab
# Turn on cache filter (off by default)
echo 1 > /sys/kernel/debug/failslab/cache-filter
# Turn on fault injection
echo 1 > /sys/kernel/debug/failslab/times
echo 1 > /sys/kernel/debug/failslab/probability

Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Akinobu Mita <akinobu.mita@gmail.com>
Acked-by: Christoph Lameter <cl@linux-foundation.org>
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
readahead: introduce FMODE_RANDOM for POSIX_FADV_RANDOM

This fixes inefficient page-by-page reads on POSIX_FADV_RANDOM.

POSIX_FADV_RANDOM used to set ra_pages=0, which leads to poor performance:
a 16K read will be carried out in 4 _sync_ 1-page reads.

In other places, ra_pages==0 means
- it's ramfs/tmpfs/hugetlbfs/sysfs/configfs
- some IO error happened
where multi-page read IO won't help or should be avoided.

POSIX_FADV_RANDOM actually want a different semantics: to disable the
*heuristic* readahead algorithm, and to use a dumb one which faithfully
submit read IO for whatever application requests.

So introduce a flag FMODE_RANDOM for POSIX_FADV_RANDOM.

Note that the random hint is not likely to help random reads performance
noticeably.  And it may be too permissive on huge request size (its IO
size is not limited by read_ahead_kb).

In Quentin's report (http://lkml.org/lkml/2009/12/24/145), the overall
(NFS read) performance of the application increased by 313%!

Tested-by: Quentin Barnes <qbarnes+nfs@yahoo-inc.com>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Cc: Nick Piggin <npiggin@suse.de>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: <stable@kernel.org>			[2.6.33.x]
Cc: <qbarnes+nfs@yahoo-inc.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge remote-tracking branch 'cm-10.1-mb52x/AeroKernel' into AeroKernel