fs: Use this_cpu_xx operations in buffer.c

    Optimize various per cpu area operations through these new percpu
    operations.  These operations avoid address calculations through the
    use of segment prefixes and multiple memory references through RMW
    instructions etc.

    Reduces code size:

    Before:

    christoph@linux-2.6$ size fs/buffer.o
       text	   data	    bss	    dec	    hex	filename
      19169	     80	     28	  19277	   4b4d	fs/buffer.o

    After:

    christoph@linux-2.6$ size fs/buffer.o
       text	   data	    bss	    dec	    hex	filename
      19138	     80	     28	  19246	   4b2e	fs/buffer.o

    V3->V4:
    	- Move the use of this_cpu_inc_return into a later patch so that
    	  this one can go in without percpu infrastructure changes.

    Cc: Wu Fengguang <fengguang.wu@intel.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Acked-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Christoph Lameter <cl@linux.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
percpu: Generic support for this_cpu_add, sub, dec, inc_return

    Introduce generic support for this_cpu_add_return etc.

    The fallback is to realize these operations with simpler __this_cpu_ops.

    tj: - Reformatted __cpu_size_call_return2() to make it more consistent
          with its neighbors.
        - Dropped unnecessary temp variable ret__ from
          __this_cpu_generic_add_return().

    Reviewed-by: Tejun Heo <tj@kernel.org>
    Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Acked-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Christoph Lameter <cl@linux.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
fs: Use this_cpu_inc_return in buffer.c

    __this_cpu_inc can create a single instruction with the same effect
    as the _get_cpu_var(..)++ construct in buffer.c.

    Cc: Wu Fengguang <fengguang.wu@intel.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Acked-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Christoph Lameter <cl@linux.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
lib/checksum.c: optimize do_csum a bit

Reduce the number of variables modified by the loop in do_csum() by 1,
which seems like a good idea.  On Nios II (a RISC CPU with 3-operand
instruction set) it reduces the loop from 7 to 6 instructions, including
the conditional branch.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
writeback: do uninterruptible sleep in balance_dirty_pages()

Using TASK_INTERRUPTIBLE in balance_dirty_pages() seems wrong.  If it's
going to do that then it must break out if signal_pending(), otherwise
it's pretty much guaranteed to degenerate into a busywait loop.  Plus we
*do* want these processes to appear in D state and to contribute to load
average.

So it should be TASK_UNINTERRUPTIBLE.                 -- Andrew Morton

Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
deactivate invalidated pages

Recently, there are reported problem about thrashing.
(http://marc.info/?l=rsync&amp;m=128885034930933&amp;w=2)
It happens by backup workloads(ex, nightly rsync).
That's because the workload makes just use-once pages
and touches pages twice. It promotes the page into
active list so that it results in working set page eviction.

Some app developer want to support POSIX_FADV_NOREUSE.
But other OSes don't support it, either.
(http://marc.info/?l=linux-mm&amp;m=128928979512086&amp;w=2)

By other approach, app developers use POSIX_FADV_DONTNEED.
But it has a problem. If kernel meets page is writing
during invalidate_mapping_pages, it can't work.
It makes for application programmer to use it since they always
have to sync data before calling fadivse(..POSIX_FADV_DONTNEED) to
make sure the pages could be discardable. At last, they can't use
deferred write of kernel so that they could see performance loss.
(http://insights.oetiker.ch/linux/fadvise.html)

In fact, invalidation is very big hint to reclaimer.
It means we don't use the page any more. So let's move
the writing page into inactive list's head if we can't truncate
it right now.

Why I move page to head of lru on this patch, Dirty/Writeback page
would be flushed sooner or later. It can prevent writeout of pageout
which is less effective than flusher's writeout.

Originally, I reused lru_demote of Peter with some change so added
his Signed-off-by.

Reported-by: Ben Gamari <bgamari.foss@gmail.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Rik van Riel <riel@redhat.com>
Acked-by: Mel Gorman <mel@csn.ul.ie>
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
clocksource: Add __clocksource_updatefreq_hz_khz methods
clockevents: Remove the per cpu tick skew
tracing: don't trace the BKL

    No reason to trace it when the last user is gone.

    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
cpu-hotplug: Add the function 'cpu_hotplug_inprogress'

Allows a caller to detect whether a cpu hotplug operation
is in progress. This is useful for optimizing code paths
based on this condition.

Signed-off-by: Maya Spivak <mspivak@codeaurora.org>
(cherry picked from commit 9f6cabec8fd0d0cb95084d18ee7cddbcf922ac2d)

Change-Id: I2eae7fbb819e3a776dba77a061eb89f30ac3176d
Signed-off-by: Swetha Basineni <sbasin@codeaurora.org>
printk: Don't allow cpu to get console lock during hotplugging

The flush of the console takes unnecessary time during the cpu
hotplug up operation.  It can delay the rcu synchronize_sched
operation, which in turn delays the hotplug operation. The flush
delays rcu synchronize_sched during scheduling domain creation
by up to 100 ms by interrupting the move to a quiescent state.
This change delays the flush of the console to later in the
notification chain of cpu_online. At the point in the cpu_up
operation where the flush now occurs, other tasks can already
be scheduled on the cpu that just came up.

Signed-off-by: Maya Spivak <mspivak@codeaurora.org>
(cherry picked from commit c7108258d7e44b56842f8215e31d7310f86febaa)

Change-Id: I2986071a5b05760e05d86da2f33ea2a9fe882469
Signed-off-by: Swetha Basineni <sbasin@codeaurora.org>
genirq: fix handle_nested_irq for lazy disable

    When lazy disabling is implemented and an interrupt is disabled the
    genirq code ends up marking it as IRQ_DISABLED in the descriptor.
    The interrupt stays enabled in the controller.  If the interrupt
    fires after disabling, the flow handlers namely handle_level_irq and
    handle_edge_irq mask the interrupt in the controller.

    This is not the case with handle_nested_irq. The interrupt stays enabled in
    the controller and if it were a level interrupt it keeps firing only to be
    ignored by handle_nested_irq.

    Update handle_nested_irq to mask such an interrupt.

    CRs-Fixed: 300931
    Change-Id: Iea5eee19f9b20aed40978fa124308f8cab6ac46f
    Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Fixed ext4 disk write performance regression.
jbd2: clear BH_Delay & BH_Unwritten in journal_unmap_buffer

commit 15291164b22a357cb211b618adfef4fa82fc0de3 upstream.

journal_unmap_buffer()'s zap_buffer: code clears a lot of buffer head
state ala discard_buffer(), but does not touch _Delay or _Unwritten as
discard_buffer() does.

This can be problematic in some areas of the ext4 code which assume
that if they have found a buffer marked unwritten or delay, then it's
a live one.  Perhaps those spots should check whether it is mapped
as well, but if jbd2 is going to tear down a buffer, let's really
tear it down completely.

Without this I get some fsx failures on sub-page-block filesystems
up until v3.2, at which point 4e96b2dbbf1d7e81f22047a50f862555a6cb87cb
and 189e868fa8fdca702eb9db9d8afc46b5cb9144c9 make the failures go
away, because buried within that large change is some more flag
clearing.  I still think it's worth doing in jbd2, since
->invalidatepage leads here directly, and it's the right place
to clear away these flags.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

(cherry picked from commit e4f7c341d6c6a78830dc918b23157ccfc399d397)
ext4: ignore EXT4_INODE_JOURNAL_DATA flag with delalloc

commit 3d2b158262826e8b75bbbfb7b97010838dd92ac7 upstream.

Ext4 does not support data journalling with delayed allocation enabled.
We even do not allow to mount the file system with delayed allocation
and data journalling enabled, however it can be set via FS_IOC_SETFLAGS
so we can hit the inode with EXT4_INODE_JOURNAL_DATA set even on file
system mounted with delayed allocation (default) and that's where
problem arises. The easies way to reproduce this problem is with the
following set of commands:

 mkfs.ext4 /dev/sdd
 mount /dev/sdd /mnt/test1
 dd if=/dev/zero of=/mnt/test1/file bs=1M count=4
 chattr +j /mnt/test1/file
 dd if=/dev/zero of=/mnt/test1/file bs=1M count=4 conv=notrunc
 chattr -j /mnt/test1/file

Additionally it can be reproduced quite reliably with xfstests 272 and
269. In fact the above reproducer is a part of test 272.

To fix this we should ignore the EXT4_INODE_JOURNAL_DATA inode flag if
the file system is mounted with delayed allocation. This can be easily
done by fixing ext4_should_*_data() functions do ignore data journal
flag when delalloc is set (suggested by Ted). We also have to set the
appropriate address space operations for the inode (again, ignoring data
journal flag if delalloc enabled).

Additionally this commit introduces ext4_inode_journal_mode() function
because ext4_should_*_data() has already had a lot of common code and
this change is putting it all into one function so it is easier to
read.

Successfully tested with xfstests in following configurations:

delalloc + data=ordered
delalloc + data=writeback
data=journal
nodelalloc + data=ordered
nodelalloc + data=writeback
nodelalloc + data=journal

Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

(cherry picked from commit df3c660b5745e71665270141ced3fff82a4b0aa6)

Conflicts:

	fs/ext4/ext4_jbd2.h
ext4: check for zero length extent

commit 31d4f3a2f3c73f279ff96a7135d7202ef6833f12 upstream.

Explicitly test for an extent whose length is zero, and flag that as a
corrupted extent.

This avoids a kernel BUG_ON assertion failure.

Tested: Without this patch, the file system image found in
tests/f_ext_zero_len/image.gz in the latest e2fsprogs sources causes a
kernel panic.  With this patch, an ext4 file system error is noted
instead, and the file system is marked as being corrupted.

https://bugzilla.kernel.org/show_bug.cgi?id=42859

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

(cherry picked from commit 471320c7569290aeed04f9c730d92b67b9acb53d)
ext4: add missing save_error_info() to ext4_error()

The ext4_error() function is missing a call to save_error_info().
Since this is the function which marks the file system as containing
an error, this oversight (which was introduced in 2.6.36) is quite
significant, and should be backported to older stable kernels with
high urgency.

Change-Id: Ia1eb8d91f37ceb67faf3b79d6bc79b899f1d6bfc
Reported-by: Ken Sumrall <ksumrall@google.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: ksumrall@google.com
Cc: stable@kernel.org
Signed-off-by: Ken Sumrall <ksumrall@android.com>
ADD: Lowered vfs_cache_pressure 100 -> 75
TWEAK: Lower vfs_cache_pressure again 75->25
UPDATE: fix ctnetlink_parse_tuple()