percpu: zero memory more efficiently in mm/percpu.c::pcpu_mem_alloc()

Don't do vmalloc() + memset() when vzalloc() will do.

tj: dropped unnecessary temp variable ptr.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Tejun Heo <tj@kernel.org>

============
Tuned drivers/cpufreq/cpufreq_ondemand.c

============
leveled voltage for CPU as for all normal 1Ghz cpu phones

============
Added new lowmemkiller advanced with swap support from Shooter-2.6.35-MR

===========
Tuned the shrinker function as in 2.6.35 kernel.
mm: remove unused get_vm_area_node

get_vm_area_node() is unused in the kernel and can thus be removed.

Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mm: convert sprintf_symbol to %pS

Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Pekka Enberg <penberg@kernel.org>
Cc: Jiri Kosina <trivial@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mmc: core: Increase write data timeout value for bad SDHC cards

SD2.0 specification says the max. timeout for writes is 250msecs
for SDHC cards. But when the card is almost full and there are too few
free sectors, the garbage collectors inside SD card  may take more time
and hence delaying the write more than 250msecs. This typically happens
with cards that don't adhere to specification. Based on this the timeout
is increased to 300msecs but still for some cards this is not sufficient.

Few SanDisk class4 SD cards violate the spec. and may take more time than
expected when the card is full. So increase the data timeout to 800msecs,
otherwise we might see file system corruption due to loss of important FS
metadata in timeouts.

Change-Id: Ie8f0616dbbb2a15d7dbe95cd49eeb2308a5badd1
Signed-off-by: Sujith Reddy Thumma <sthumma@codeaurora.org>
pmem: fix buddy free memory corruption bug

Enforce explicit upper limit for buddy index during memory free
operations. This index is generated during memory free operations of
the buddy bestfit allocator. The index points to each free buddy that
should be coalesced into a greater free memory area. The upper limit
now enforced is the number of entries in the current PMEM region.

Without this fix, pmem_buddy_bestfit_free would continue to corrupt
bytes in ever higher addresses, by power of 2, of memory until
stopped by the high bit being set in the currently examined byte.
Unless the high bit was set immediately at the first invalid byte,
this could have caused memory corruption past the current pmem region
metadata in kernel memory space.

One manifestation of this problem was a corner case where
non-existent buddies were incorrectly coalesced.

In a 12MB region, the buddy free for 8MB tried to coalesce the freed
buddy metadata with a non-existent 8MB buddy which actually belonged
to the following region. This caused the order number in the metadata
belonging to the following region to be incorrectly incremented past
the region boundary. Soon after, there was a subsequent invalid
allocation in that following region past the region boundary.

Signed-off-by: Stephen Biggs <sbiggs@quicinc.com>
mm: add vzalloc() and vzalloc_node() helpers

Add vzalloc() and vzalloc_node() to encapsulate the
vmalloc-then-memset-zero operation.

Use __GFP_ZERO to zero fill the allocated memory.

Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Cc: Christoph Lameter <cl@linux-foundation.org>
Acked-by: Greg Ungerer <gerg@snapgear.com>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[mm] various memory bugfixes and tweaks

ARM: 6941/1: cache: ensure MVA is cacheline aligned in flush_kern_dcache_area

    commit a248b13b21ae00b97638b4f435c8df3075808b5d upstream.

    The v6 and v7 implementations of flush_kern_dcache_area do not align
    the passed MVA to the size of a cacheline in the data cache. If a
    misaligned address is used, only a subset of the requested area will
    be flushed. This has been observed to cause failures in SMP boot where
    the secondary_data initialised by the primary CPU is not cacheline
    aligned, causing the secondary CPUs to read incorrect values for their
    pgd and stack pointers.

    This patch ensures that the base address is cacheline aligned before
    flushing the d-cache.

    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

mm/page_alloc.c: prevent unending loop in __alloc_pages_slowpath()

    commit cfa54a0fcfc1017c6f122b6f21aaba36daa07f71 upstream.

    I believe I found a problem in __alloc_pages_slowpath, which allows a
    process to get stuck endlessly looping, even when lots of memory is
    available.

    Running an I/O and memory intensive stress-test I see a 0-order page
    allocation with __GFP_IO and __GFP_WAIT, running on a system with very
    little free memory.  Right about the same time that the stress-test gets
    killed by the OOM-killer, the utility trying to allocate memory gets stuck
    in __alloc_pages_slowpath even though most of the systems memory was freed
    by the oom-kill of the stress-test.

    The utility ends up looping from the rebalance label down through the
    wait_iff_congested continiously.  Because order=0,
    __alloc_pages_direct_compact skips the call to get_page_from_freelist.
    Because all of the reclaimable memory on the system has already been
    reclaimed, __alloc_pages_direct_reclaim skips the call to
    get_page_from_freelist.  Since there is no __GFP_FS flag, the block with
    __alloc_pages_may_oom is skipped.  The loop hits the wait_iff_congested,
    then jumps back to rebalance without ever trying to
    get_page_from_freelist.  This loop repeats infinitely.

    The test case is pretty pathological.  Running a mix of I/O stress-tests
    that do a lot of fork() and consume all of the system memory, I can pretty
    reliably hit this on 600 nodes, in about 12 hours.  32GB/node.

    Signed-off-by: Andrew Barry <abarry@cray.com>
    Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
    Reviewed-by: Rik van Riel<riel@redhat.com>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

vmalloc: remove redundant unlikely()

    IS_ERR() already implies unlikely(), so it can be omitted here.

    Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
    Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: remove likely() from mapping_unevictable()

    The mapping_unevictable() has a likely() around the mapping parameter.
    This mapping parameter comes from page_mapping() which has an unlikely()
    that the page will be set as PAGE_MAPPING_ANON, and if so, it will return
    NULL.  One would think that this unlikely() means that the mapping
    returned by page_mapping() would not be NULL, but where page_mapping() is
    used just above mapping_unevictable(), that unlikely() is incorrect most
    of the time.  This means that the "likely(mapping)" in
    mapping_unevictable() is incorrect most of the time.

    Running the annotated branch profiler on my main box which runs firefox,
    evolution, xchat and is part of my distcc farm, I had this:

     correct incorrect  %        Function                  File              Line
     ------- ---------  -        --------                  ----              ----
    12872836 1269443893  98 mapping_unevictable            pagemap.h            51
    35935762 1270265395  97 page_mapping                   mm.h                 659
    1306198001   143659   0 page_mapping                   mm.h                 657
    203131478   121586   0 page_mapping                   mm.h                 657
     5415491     1116   0 page_mapping                   mm.h                 657
    74899487     1116   0 page_mapping                   mm.h                 657
    203132845      224   0 page_mapping                   mm.h                 659
     5415464       27   0 page_mapping                   mm.h                 659
       13552        0   0 page_mapping                   mm.h                 657
       13552        0   0 page_mapping                   mm.h                 659
      242630        0   0 page_mapping                   mm.h                 657
      242630        0   0 page_mapping                   mm.h                 659
    74899487        0   0 page_mapping                   mm.h                 659

    The page_mapping() is a static inline, which is why it shows up multiple
    times.  The mapping_unevictable() is also a static inline but seems to be
    used only once in my setup.

    The unlikely in page_mapping() was correct a total of 1909540379 times and
    incorrect 1270533123 times, with a 39% being incorrect.  Perhaps this is
    enough to remove the unlikely from page_mapping() as well.

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Acked-by: Nick Piggin <npiggin@kernel.dk>
    Acked-by: Rik van Riel <riel@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: remove unlikely() from page_mapping()

    page_mapping() has a unlikely that the mapping has PAGE_MAPPING_ANON set.
    But running the annotated branch profiler on a normal desktop system doing
    vairous tasks (xchat, evolution, firefox, distcc), it is not really that
    unlikely that the mapping here will have the PAGE_MAPPING_ANON flag set:

     correct incorrect  %        Function                  File              Line
     ------- ---------  -        --------                  ----              ----
    35935762 1270265395  97 page_mapping                   mm.h                 659
    1306198001   143659   0 page_mapping                   mm.h                 657
    203131478   121586   0 page_mapping                   mm.h                 657
     5415491     1116   0 page_mapping                   mm.h                 657
    74899487     1116   0 page_mapping                   mm.h                 657
    203132845      224   0 page_mapping                   mm.h                 659
     5415464       27   0 page_mapping                   mm.h                 659
       13552        0   0 page_mapping                   mm.h                 657
       13552        0   0 page_mapping                   mm.h                 659
      242630        0   0 page_mapping                   mm.h                 657
      242630        0   0 page_mapping                   mm.h                 659
    74899487        0   0 page_mapping                   mm.h                 659

    The page_mapping() is a static inline, which is why it shows up multiple
    times.

    The unlikely in page_mapping() was correct a total of 1909540379 times and
    incorrect 1270533123 times, with a 39% being incorrect.  With this much of
    an error, it's best to simply remove the unlikely and have the compiler
    and branch prediction figure this out.

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Nick Piggin <npiggin@kernel.dk>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: remove likely() from grab_cache_page_write_begin()

    Running the annotated branch profiler on a box doing average work
    (firefox, evolution, xchat, distcc farm), the likely() used in
    grab_cache_page_write_begin() was incorrect most of the time:

     correct incorrect  %        Function                  File              Line
     ------- ---------  -        --------                  ----              ----
     1924262 71332401  97 grab_cache_page_write_begin    filemap.c           2206

    Adding a trace_printk() and running the function tracer limited to
    just this function I can see:

            gconfd-2-2696  [000]  4467.268935: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=7
            gconfd-2-2696  [000]  4467.268946: grab_cache_page_write_begin <-ext3_write_begin
            gconfd-2-2696  [000]  4467.268947: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=8
            gconfd-2-2696  [000]  4467.268959: grab_cache_page_write_begin <-ext3_write_begin
            gconfd-2-2696  [000]  4467.268960: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=9
            gconfd-2-2696  [000]  4467.268972: grab_cache_page_write_begin <-ext3_write_begin
            gconfd-2-2696  [000]  4467.268973: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=10
            gconfd-2-2696  [000]  4467.268991: grab_cache_page_write_begin <-ext3_write_begin
            gconfd-2-2696  [000]  4467.268992: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=11
            gconfd-2-2696  [000]  4467.269005: grab_cache_page_write_begin <-ext3_write_begin

    Which shows that a lot of calls from ext3_write_begin will result in the
    page returned by "find_lock_page" will be NULL.

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Acked-by: Nick Piggin <npiggin@kernel.dk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

writeback: avoid unnecessary determine_dirtyable_memory call

    I think determine_dirtyable_memory() is a rather costly function since it
    need many atomic reads for gathering zone/global page state.  But when we
    use vm_dirty_bytes && dirty_background_bytes, we don't need that costly
    calculation.

    This patch eliminates such unnecessary overhead.

    NOTE : newly added if condition might add overhead in normal path.
           But it should be _really_ small because anyway we need the
           access both vm_dirty_bytes and dirty_background_bytes so it is
           likely to hit the cache.

    [akpm@linux-foundation.org: fix used-uninitialised warning]
    Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
    Cc: Wu Fengguang <fengguang.wu@intel.com>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

brk: fix min_brk lower bound computation for COMPAT_BRK

    Even if CONFIG_COMPAT_BRK is set in the kernel configuration, it can still
    be overriden by randomize_va_space sysctl.

    If this is the case, the min_brk computation in sys_brk() implementation
    is wrong, as it solely takes into account COMPAT_BRK setting, assuming
    that brk start is not randomized.  But that might not be the case if
    randomize_va_space sysctl has been set to '2' at the time the binary has
    been loaded from disk.

    In such case, the check has to be done in a same way as in
    !CONFIG_COMPAT_BRK case.

    In addition to that, the check for the COMPAT_BRK case introduced back in
    a5b4592c ("brk: make sys_brk() honor COMPAT_BRK when computing lower
    bound") is slightly wrong -- the lower bound shouldn't be mm->end_code,
    but mm->end_data instead, as that's where the legacy applications expect
    brk section to start (i.e.  immediately after last global variable).

    [akpm@linux-foundation.org: fix comment]
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm/page_alloc.c: simplify calculation of combined index of adjacent buddy lists

    The previous approach of calucation of combined index was

    	page_idx & ~(1 << order))

    but we have same result with

    	page_idx & buddy_idx

    This reduces instructions slightly as well as enhances readability.

    [akpm@linux-foundation.org: coding-style fixes]
    [akpm@linux-foundation.org: fix used-unintialised warning]
    Signed-off-by: KyongHo Cho <pullip.cho@samsung.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm/dmapool.c: take lock only once in dma_pool_free()

    dma_pool_free() scans for the page to free in the pool list holding the
    pool lock.  Then it releases the lock basically to acquire it immediately
    again.  Modify the code to only take the lock once.

    This will do some additional loops and computations with the lock held in
    if memory debugging is activated.  If it is not activated the only new
    operations with this lock is one if and one substraction.

    Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm/dmapool.c: use TASK_UNINTERRUPTIBLE in dma_pool_alloc()

    As it stands this code will degenerate into a busy-wait if the calling task
    has signal_pending().

    Cc: Rolf Eike Beer <eike-kernel@sf-tec.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>