ext4: speed up truncate/unlink by not using bforget() unless needed
Do not iterate over data blocks scanning for bh's to forget as they're
never exist. This improves time taken by unlink / truncate syscall.
Tested by continuously truncating file that is being written by dd.
Another test is rm -rf of linux tree while tar unpacks it. With
ordered data mode condition unlikely(!tbh) was always met in
ext4_free_blocks. With journal data mode tbh was found only few times,
so optimisation is also possible.

Unlinking fallocated 60G file after doing sync && echo 3 >
/proc/sys/vm/drop_caches && time rm --help

X86 before (linux 3.6-rc4):
real    0m2.710s
user    0m0.000s
sys     0m1.530s

X86 after:
real    0m0.644s
user    0m0.003s
sys     0m0.060s

MIPS before (linux 2.6.37):
real    0m 4.93s
user    0m 0.00s
sys     0m 4.61s

MIPS after:
real    0m 0.16s
user    0m 0.00s
sys     0m 0.06s

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Andrey Sidorov <qrxd43@motorola.com>
Signed-off-by: Jean Francis Dominique S. Mabalot <jfdsmabalot@redhat.com>
writeback: fix occasional slow sync && fix race that cause writeback hung
1) fix occasional slow sync

In case when system contains no dirty pages, wakeup_flusher_threads() will
submit WB_SYNC_NONE writeback for 0 pages so wb_writeback() exits
immediately without doing anything, even though there are dirty inodes in
the system.  Thus sync(1) will write all the dirty inodes from a
WB_SYNC_ALL writeback pass which is slow.

Fix the problem by using get_nr_dirty_pages() in wakeup_flusher_threads()
instead of calculating number of dirty pages manually.  That function also
takes number of dirty inodes into account.

Signed-off-by: Jan Kara <jack@suse.cz>
Reported-by: Paul Taysom <taysom@chromium.org>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

2) fix race that cause writeback hung

There is a race between mark inode dirty and writeback thread, see the
following scenario.  In this case, writeback thread will not run though
there is dirty_io.

__mark_inode_dirty()                                          bdi_writeback_workfn()
	...                                                       	...
	spin_lock(&inode->i_lock);
	...
	if (bdi_cap_writeback_dirty(bdi)) {
	    <<< assume wb has dirty_io, so wakeup_bdi is false.
	    <<< the following inode_dirty also have wakeup_bdi false.
	    if (!wb_has_dirty_io(&bdi->wb))
		    wakeup_bdi = true;
	}
	spin_unlock(&inode->i_lock);
	                                                            <<< assume last dirty_io is removed here.
	                                                            pages_written = wb_do_writeback(wb);
	                                                            ...
	                                                            <<< work_list empty and wb has no dirty_io,
	                                                            <<< delayed_work will not be queued.
	                                                            if (!list_empty(&bdi->work_list) ||
	                                                                (wb_has_dirty_io(wb) && dirty_writeback_interval))
	                                                                queue_delayed_work(bdi_wq, &wb->dwork,
	                                                                    msecs_to_jiffies(dirty_writeback_interval * 10));
	spin_lock(&bdi->wb.list_lock);
	inode->dirtied_when = jiffies;
	<<< new dirty_io is added.
	list_move(&inode->i_wb_list, &bdi->wb.b_dirty);
	spin_unlock(&bdi->wb.list_lock);

	<<< though there is dirty_io, but wakeup_bdi is false,
	<<< so writeback thread will not be waked up and
	<<< the new dirty_io will not be flushed.
	if (wakeup_bdi)
	    bdi_wakeup_thread_delayed(bdi);

Writeback will run until there is a new flush work queued.  This may cause
a lot of dirty pages stay in memory for a long time.

Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Squashed:
Signed-off-by: Jean Francis Dominique S. Mabalot <jfdsmabalot@redhat.com>
ARM: LoUIS cache maintenance API

 ARM v7 architecture introduced the concept of cache levels and related
 coherency requirements. New processors like A7 and A15 embed an
 L2 unified cache controller that becomes part of the cache level
 hierarchy. Some operations in the kernel like cpu_suspend and __cpu_disable
 does not require a flush of the entire cache hierarchy to DRAM but just the
 cache levels belonging to the Level of Unification Inner Shareable (LoUIS),
 which in most of ARM v7 systems correspond to L1.
 The current cache flushing API used in cpu_suspend and __cpu_disable,
 flush_cache_all(), ends up flushing the whole cache hierarchy since for
 v7 it cleans and invalidates all cache levels up to Level of Coherency
 (LoC) which cripples system performance when used in hot paths like hotplug
 and cpuidle.

 Therefore a new kernel cache maintenance API must be added to the
 cpu_cache_fns structure of pointers to cope with latest ARM system requirements.
 This patch adds flush_cache_louis() to the ARM kernel cache maintenance API.

 This function cleans and invalidates all data cache levels up to the
 level of unification inner shareable (LoUIS) and invalidates the instruction
 cache.

 The cpu_cache_fns struct reflects this change by adding a new function pointer
 that is initialized by arch specific assembly files.

 By default, all existing ARM archs do not instantiate any cache LoUIS function
 pointer, and flush_dcache_louis just falls back to flush_kern_all.

 Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
 Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>

Initial adaptation for msm8974

Signed-off-by: Jean Francis Dominique S. Mabalot <jfdsmabalot@redhat.com>
Signed-off-by: Anonymous <kernelhackx@gmx.com>