Patched and Backported Joe's RCU to 2.6.35 kernel
fs: lower vfs_cache_pressure 100->25
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>
ARM: Add optimised swahb32() byteswap helper for v6 and above

ARMv6 and later processors have the REV16 instruction, which swaps
the bytes within each halfword of a register value.

This is already used to implement swab16(), but since the native
operation performaed by REV16 is actually swahb32(), this patch
renames the existing swab16() helper accordingly and defines
__arch_swab16() in terms of it.  This allows calls to both swab16()
and swahb32() to be optimised.

The compiler's generated code might improve someday, but as of
4.5.2 the code generated for pure C implementing these 16-bit
bytesswaps remains pessimal.

swahb32() is useful for converting 32-bit Thumb instructions
between integer and memory representation on BE8 platforms (among
other uses).

Signed-off-by: Dave Martin <dave.martin@xxxxxxxxxx>
dm io: remove BIO_RW_SYNCIO flag from kcopyd

Remove the REQ_SYNC flag to improve write throughput when writing
to the origin with a snapshot on the same device (using the CFQ I/O
scheduler).

Sequential write throughput (chunksize of 4k, 32k, 512k)
  unpatched:  8.5,  8.6,  9.3 MB/s
  patched:   15.2, 18.5, 17.5 MB/s

Snapshot exception reallocations are triggered by writes that are
usually async, so mark the associated dm_io_request as async as well.
This helps when using the CFQ I/O scheduler because it has separate
queues for sync and async I/O.  Async is optimized for throughput; sync
for latency.  With this change we're consciously favoring throughput over
latency.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
ext2: speed up file creates by optimizing rec_len functions

The addition of 64k block capability in the rec_len_from_disk
and rec_len_to_disk functions added a bit of math overhead which
slows down file create workloads needlessly when the architecture
cannot even support 64k blocks, thanks to page size limits.

The directory entry checking can also be optimized a bit
by sprinkling in some unlikely() conditions to move the
error handling out of line.

bonnie++ sequential file creates on a 512MB ramdisk speeds up
from about 2200/s to about 2500/s, about a 14% improvement.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
ext3: speed up file creates by optimizing rec_len functions

The addition of 64k block capability in the rec_len_from_disk
and rec_len_to_disk functions added a bit of math overhead which
slows down file create workloads needlessly when the architecture
cannot even support 64k blocks, thanks to page size limits.

Similar changes already exist in the ext4 codebase.

The directory entry checking can also be optimized a bit
by sprinkling in some unlikely() conditions to move the
error handling out of line.

bonnie++ sequential file creates on a 512MB ramdisk speeds up
from about 77,000/s to about 82,000/s, about a 6% improvement.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
vmalloc: remove confusing comment on vwrite()

KM_USER1 is never used for vwrite() path so the caller doesn't need to
guarantee it is not used.  Only the caller should guarantee is KM_USER0
and it is commented already.

Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.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>
mm: Allow compaction without HugeTLB

Memory compaction can be enabled without enabling
HUGETLB support.

Change-Id: I449ee24205f8139dbe0c198b045c5a66917801b2
Signed-off-by: Brian Steuer <bsteuer@codeaurora.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>
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: 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>
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: remove gfp mask from pcpu_get_vm_areas

pcpu_get_vm_areas() only uses GFP_KERNEL allocations, so remove the gfp_t
formal and use the mask internally.

Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mm: vmap area cache

Provide a free area cache for the vmalloc virtual address allocator, based
on the algorithm used by the user virtual memory allocator.

This reduces the number of rbtree operations and linear traversals over
the vmap extents in order to find a free area, by starting off at the last
point that a free area was found.

The free area cache is reset if areas are freed behind it, or if we are
searching for a smaller area or alignment than last time.  So allocation
patterns are not changed (verified by corner-case and random test cases in
userspace testing).

This solves a regression caused by lazy vunmap TLB purging introduced in
db64fe02 (mm: rewrite vmap layer).  That patch will leave extents in the
vmap allocator after they are vunmapped, and until a significant number
accumulate that can be flushed in a single batch.  So in a workload that
vmalloc/vfree frequently, a chain of extents will build up from
VMALLOC_START address, which have to be iterated over each time (giving an
O(n) type of behaviour).

After this patch, the search will start from where it left off, giving
closer to an amortized O(1).

This is verified to solve regressions reported Steven in GFS2, and Avi in
KVM.

Hugh's update:

: I tried out the recent mmotm, and on one machine was fortunate to hit
: the BUG_ON(first->va_start < addr) which seems to have been stalling
: your vmap area cache patch ever since May.

: I can get you addresses etc, I did dump a few out; but once I stared
: at them, it was easier just to look at the code: and I cannot see how
: you would be so sure that first->va_start < addr, once you've done
: that addr = ALIGN(max(...), align) above, if align is over 0x1000
: (align was 0x8000 or 0x4000 in the cases I hit: ioremaps like Steve).

: I originally got around it by just changing the
: 		if (first->va_start < addr) {
: to
: 		while (first->va_start < addr) {
: without thinking about it any further; but that seemed unsatisfactory,
: why would we want to loop here when we've got another very similar
: loop just below it?

: I am never going to admit how long I've spent trying to grasp your
: "while (n)" rbtree loop just above this, the one with the peculiar
: 		if (!first && tmp->va_start < addr + size)
: in.  That's unfamiliar to me, I'm guessing it's designed to save a
: subsequent rb_next() in a few circumstances (at risk of then setting
: a wrong cached_hole_size?); but they did appear few to me, and I didn't
: feel I could sign off something with that in when I don't grasp it,
: and it seems responsible for extra code and mistaken BUG_ON below it.

: I've reverted to the familiar rbtree loop that find_vma() does (but
: with va_end >= addr as you had, to respect the additional guard page):
: and then (given that cached_hole_size starts out 0) I don't see the
: need for any complications below it.  If you do want to keep that loop
: as you had it, please add a comment to explain what it's trying to do,
: and where addr is relative to first when you emerge from it.

: Aren't your tests "size <= cached_hole_size" and
: "addr + size > first->va_start" forgetting the guard page we want
: before the next area?  I've changed those.

: I have not changed your many "addr + size - 1 < addr" overflow tests,
: but have since come to wonder, shouldn't they be "addr + size < addr"
: tests - won't the vend checks go wrong if addr + size is 0?

: I have added a few comments - Wolfgang Wander's 2.6.13 description of
: 1363c3cd8603a913a27e2995dccbd70d5312d8e6 Avoiding mmap fragmentation
: helped me a lot, perhaps a pointer to that would be good too.  And I found
: it easier to understand when I renamed cached_start slightly and moved the
: overflow label down.

: This patch would go after your mm-vmap-area-cache.patch in mmotm.
: Trivially, nobody is going to get that BUG_ON with this patch, and it
: appears to work fine on my machines; but I have not given it anything like
: the testing you did on your original, and may have broken all the
: performance you were aiming for.  Please take a look and test it out
: integrate with yours if you're satisfied - thanks.

[akpm@linux-foundation.org: add locking comment]
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Hugh Dickins <hughd@google.com>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
Reported-and-tested-by: Steven Whitehouse <swhiteho@redhat.com>
Reported-and-tested-by: Avi Kivity <avi@redhat.com>
Tested-by: "Barry J. Marson" <bmarson@redhat.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mm: unify module_alloc code for vmalloc

Four architectures (arm, mips, sparc, x86) use __vmalloc_area() for
module_init().  Much of the code is duplicated and can be generalized in a
globally accessible function, __vmalloc_node_range().

__vmalloc_node() now calls into __vmalloc_node_range() with a range of
[VMALLOC_START, VMALLOC_END) for functionally equivalent behavior.

Each architecture may then use __vmalloc_node_range() directly to remove
the duplication of code.

Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
PM: Fix printing IRQ names for pending wakeup IRQs

The IRQ name has moved to the struct irqaction list (so print
first action's name).

Change-Id: I65a627457f9abaf7c1dcc32d8814243ba2ff4717
Signed-off-by: Todd Poynor <toddpoynor@google.com>
PM: Wait for completion of the parent resume before resuming

If the parent device is in the DPM_RESUMING state, resume might get called
before the parent's resume has completed, because dpm_wait won't get
called. This issue was introduced by:
3d46a3c PM: Prevent waiting forever on asynchronous resume after abort

Wait for completion of the parent resume if the parent state is >= DPM_OFF
or == DPM_RESUMING

Change-Id: I14a4e16426f61efceaefedc7e772f53b7522b5dd
Signed-off-by: Benoit Goby <benoit@android.com>
PM: Introduce library for device-specific OPPs (v7)

SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.

To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.

Contributions include:
Sanjeev Premi for the initial concept:
	http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.

Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.

v1: http://marc.info/?t=128468723000002&r=1&w=2

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>