sched: Improve latencies under load by decreasing minimum scheduling granularity

Mathieu reported bad latencies with make -j10 kind of kbuild
workloads - which is mostly caused by us scheduling with a
too coarse granularity.

Reduce the minimum granularity some more, to make sure we
can meet the latency target.

I got the following results (make -j10 kbuild load, average of 3
runs):

 vanilla:

  maximum latency: 38278.9 µs
  average latency:  7730.1 µs

 patched:

  maximum latency: 22702.1 µs
  average latency:  6684.8 µs

Mathieu also measured it:

|
| * wakeup-latency.c (SIGEV_THREAD) with make -j10
|
| - Mainline 2.6.35.2 kernel
|
| maximum latency: 45762.1 µs
| average latency: 7348.6 µs
|
| - With only Peter's smaller min_gran (shown below):
|
| maximum latency: 29100.6 µs
| average latency: 6684.1 µs
|

Reported-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Suggested-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <AANLkTi=8m4g01wZPacySoF7U0PevTNVgJoZZrHiUD-pN@mail.gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
vidc: 720p: Add IDR Frame type support for H264 format - CodeAurora

Read IDR frame type from 720p core register set and
propagate it to user space using new IDR frame type
enumeration added in api header file. The IDR frame
type info is used in SYNCFRAME logic for H264 format
in userspace.

CRs-Fixed: 296738
Signed-off-by: Maheshwar Ajja <majja@codeaurora.org>
mmc: Add helper function to check if a card is removable - CodeAurora

There are two checks that need to be made when determining whether a
card is removable. A host controller may set MMC_CAP_NONREMOVABLE if the
controller does not support removing cards (e.g. eMMC), in which case
the card is physically non-removable. Also the 'mmc_assume_removable'
module parameter can be configured at module load time, in which case
the card may be logically non-removable.

A helper function keeps the logic in one place so that code always
checks both conditions.

Because this new function is likely to be called from modules we now
need to export the mmc_assume_removable symbol.
USB: gadget: android: Use "rndis%d" for RNDIS device name instead of "usb%d"

    Signed-off-by: Mike Lockwood <lockwood@android.com>
msm: cpufreq: Improve initial frequency selection - CodeAurora

    Instead of failing init when a supported scaling frequency >=
    the current CPU frequency cannot be found, also try looking for
    a supported frequency <= the current CPU rate.

    This prevents a crash if the CPU happens to be running faster
    than the highest scaling frequency at boot.

    Change-Id: I4109279055bfe72dfe35e43bb9a7bad46dd3048e
    Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
mach-msm: dal: use strlcpy instead of strncpy

strlcpy is safer as it gurantees that the resultant
string is NULL terminated

Change-Id: I9879a10656d0766354f8b0e7ed6338d25e9fbaec
Signed-off-by: Swaminathan Sathappan <Swami@codeaurora.org>
init/calibrate.c: fix for critical bogoMIPS intermittent calculation failure

    A fix to the TSC (Time Stamp Counter) based bogoMIPS calculation used on
    secondary CPUs which has two faults:

    1: Not handling wrapping of the lower 32 bits of the TSC counter on
       32bit kernel - perhaps TSC is not reset by a warm reset?

    2: TSC and Jiffies are no incrementing together properly.  Either
       jiffies increment too quickly or Time Stamp Counter isn't incremented
       in during an SMI but the real time clock is and jiffies are
       incremented.

    Case 1 can result in a factor of 16 too large a value which makes udelay()
    values too small and can cause mysterious driver errors.  Case 2 appears
    to give smaller 10-15% errors after averaging but enough to cause
    occasional failures on my own board

    I have tested this code on my own branch and attach patch suitable for
    current kernel code.  See below for examples of the failures and how the
    fix handles these situations now.

    I reported this issue earlier here:
         Intermittent problem with BogoMIPs calculation on Intel AP CPUs -
    http://marc.info/?l=linux-kernel&m=129947246316875&w=4

    I suspect this issue has been seen by others but as it is intermittent and
    bogoMIPS for secondary CPUs are no longer printed out it might have been
    difficult to identify this as the cause.  Perhaps these unresolved issues,
    although quite old, might be relevant as possibly this fault has been
    around for a while.  In particular Case 1 may only be relevant to 32bit
    kernels on newer HW (most people run 64bit kernels?).  Case 2 is less
    dramatic since the earlier fix in this area and also intermittent.

       Re: bogomips discrepancy on Intel Core2 Quad CPU -
    http://marc.info/?l=linux-kernel&m=118929277524298&w=4
       slow system and bogus bogomips  -
    http://marc.info/?l=linux-kernel&m=116791286716107&w=4
       Re: Re: [RFC-PATCH] clocksource: update lpj if clocksource has -
    http://marc.info/?l=linux-kernel&m=128952775819467&w=4

    This issue is masked a little by commit feae3203d711db0a ("timers, init:
    Limit the number of per cpu calibration bootup messages") which only
    prints out the first bogoMIPS value making it much harder to notice other
    values differing.  Perhaps it should be changed to only suppress them when
    they are similar values?

    Here are some outputs showing faults occurring and the new code handling
    them properly.  See my earlier message for examples of the original
    failure.

        Case 1:   A Time Stamp Counter wrap:
    ...
    Calibrating delay loop (skipped), value calculated using timer
    frequency.. 6332.70 BogoMIPS (lpj=31663540)
    ....
    calibrate_delay_direct() timer_rate_max=31666493
    timer_rate_min=31666151 pre_start=4170369255 pre_end=4202035539
    calibrate_delay_direct() timer_rate_max=2425955274
    timer_rate_min=2425954941 pre_start=4265368533 pre_end=2396356387
    calibrate_delay_direct() ignoring timer_rate as we had a TSC wrap
    around start=4265368581 >=post_end=2396356511
    calibrate_delay_direct() timer_rate_max=31666274
    timer_rate_min=31665942 pre_start=2440373374 pre_end=2472039515
    calibrate_delay_direct() timer_rate_max=31666492
    timer_rate_min=31666160 pre_start=2535372139 pre_end=2567038422
    calibrate_delay_direct() timer_rate_max=31666455
    timer_rate_min=31666207 pre_start=2630371084 pre_end=2662037415
    Calibrating delay using timer specific routine.. 6333.28 BogoMIPS (lpj=31666428)
    Total of 2 processors activated (12665.99 BogoMIPS).
    ....

        Case 2:  Some thing (presumably the SMM interrupt?) causing the
    very low increase in TSC counter for the DELAY_CALIBRATION_TICKS
    increase in jiffies
    ...
    Calibrating delay loop (skipped), value calculated using timer
    frequency.. 6333.25 BogoMIPS (lpj=31666270)
    ...
    calibrate_delay_direct() timer_rate_max=31666483
    timer_rate_min=31666074 pre_start=4199536526 pre_end=4231202809
    calibrate_delay_direct() timer_rate_max=864348 timer_rate_min=864016
    pre_start=2405343672 pre_end=2406207897
    calibrate_delay_direct() timer_rate_max=31666483
    timer_rate_min=31666179 pre_start=2469540464 pre_end=2501206823
    calibrate_delay_direct() timer_rate_max=31666511
    timer_rate_min=31666122 pre_start=2564539400 pre_end=2596205712
    calibrate_delay_direct() timer_rate_max=31666084
    timer_rate_min=31665685 pre_start=2659538782 pre_end=2691204657
    calibrate_delay_direct() dropping min bogoMips estimate 1 = 864348
    Calibrating delay using timer specific routine.. 6333.27 BogoMIPS (lpj=31666390)
    Total of 2 processors activated (12666.53 BogoMIPS).
    ...

    After 70 boots I saw 2 variations <1% slip through

    [akpm@linux-foundation.org: coding-style fixes]
    [akpm@linux-foundation.org: fix straggly printk mess]
    Signed-off-by: Andrew Worsley <amworsley@gmail.com>
    Reviewed-by: Phil Carmody <ext-phil.2.carmody@nokia.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
init/calibrate.c: remove annoying printk

    Remove calibrate_delay_direct()'s KERN_DEBUG printk related to bogomips
    calculation as it appears when booting every core on setups with
    'ignore_loglevel' which dmesg people scan for possible issues.  As the
    message doesn't show very useful information to the widest audience of
    kernel boot message gazers, it should be removed.

    Introduced by commit d2b463135f84 ("init/calibrate.c: fix for critical
    bogoMIPS intermittent calculation failure").

    Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
    Cc: Andrew Worsley <amworsley@gmail.com>
    Cc: Phil Carmody <ext-phil.2.carmody@nokia.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
init: skip calibration delay if previously done

    For each CPU, do the calibration delay only once.  For subsequent calls,
    use the cached per-CPU value of loops_per_jiffy.

    This saves about 200ms of resume time on dual core Intel Atom N5xx based
    systems.  This helps bring down the kernel resume time on such systems
    from about 500ms to about 300ms.

    [akpm@linux-foundation.org: make cpu_loops_per_jiffy static]
    [akpm@linux-foundation.org: clean up message text]
    [akpm@linux-foundation.org: fix things up after upstream rmk changes]
    Signed-off-by: Sameer Nanda <snanda@chromium.org>
    Cc: Phil Carmody <ext-phil.2.carmody@nokia.com>
    Cc: Andrew Worsley <amworsley@gmail.com>
    Cc: David Daney <ddaney@caviumnetworks.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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>
memcg: move memcg reclaimable page into tail of inactive list

    The rotate_reclaimable_page function moves just written out pages, which
    the VM wanted to reclaim, to the end of the inactive list.  That way the
    VM will find those pages first next time it needs to free memory.

    This patch applies the rule in memcg.  It can help to prevent unnecessary
    working page eviction of memcg.

    Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
    Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com>
    Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: reclaim invalidated page ASAP

    invalidate_mapping_pages is very big hint to reclaimer.  It means user
    doesn't want to use the page any more.  So in order to prevent working set
    page eviction, this patch move the page into tail of inactive list by
    PG_reclaim.

    Please, remember that pages in inactive list are working set as well as
    active list.  If we don't move pages into inactive list's tail, pages near
    by tail of inactive list can be evicted although we have a big clue about
    useless pages.  It's totally bad.

    Now PG_readahead/PG_reclaim is shared.  fe3cba17 added ClearPageReclaim
    into clear_page_dirty_for_io for preventing fast reclaiming readahead
    marker page.

    In this series, PG_reclaim is used by invalidated page, too.  If VM find
    the page is invalidated and it's dirty, it sets PG_reclaim to reclaim
    asap.  Then, when the dirty page will be writeback,
    clear_page_dirty_for_io will clear PG_reclaim unconditionally.  It
    disturbs this serie's goal.

    I think it's okay to clear PG_readahead when the page is dirty, not
    writeback time.  So this patch moves ClearPageReadahead.  In v4,
    ClearPageReadahead in set_page_dirty has a problem which is reported by
    Steven Barrett.  It's due to compound page.  Some driver(ex, audio) calls
    set_page_dirty with compound page which isn't on LRU.  but my patch does
    ClearPageRelcaim on compound page.  In non-CONFIG_PAGEFLAGS_EXTENDED, it
    breaks PageTail flag.

    I think it doesn't affect THP and pass my test with THP enabling but Cced
    Andrea for double check.

    Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
    Reported-by: Steven Barrett <damentz@liquorix.net>
    Reviewed-by: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: Rik van Riel <riel@redhat.com>
    Acked-by: Mel Gorman <mel@csn.ul.ie>
    Cc: Wu Fengguang <fengguang.wu@intel.com>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Nick Piggin <npiggin@kernel.dk>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: simplify code of swap.c

    Clean up code and remove duplicate code. Next patch will use
    pagevec_lru_move_fn introduced here too.

    Signed-off-by: Shaohua Li <shaohua.li@intel.com>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Hiroyuki Kamezawa <kamezawa.hiroyuki@gmail.com>
    Cc: Andi Kleen <andi@firstfloor.org>
    Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mm: check PageUnevictable in lru_deactivate_fn()

    The lru_deactivate_fn should not move page which in on unevictable lru
    into inactive list.  Otherwise, we can meet BUG when we use
    isolate_lru_pages as __isolate_lru_page could return -EINVAL.

    Reported-by: Ying Han <yinghan@google.com>
    Tested-by: Ying Han <yinghan@google.com>
    Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
    Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Reviewed-by: Rik van Riel<riel@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mm: filter unevictable page out in deactivate_page()

    It's pointless that deactive_page's operates on unevictable pages.  This
    patch removes unnecessary overhead which might be a bit problem in case
    that there are many unevictable page in system(ex, mprotect workload)

    [akpm@linux-foundation.org: tidy up comment]
    Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
    Reviewed-by: Rik van Riel<riel@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mm: batch activate_page() to reduce lock contention

    The zone->lru_lock is heavily contented in workload where activate_page()
    is frequently used.  We could do batch activate_page() to reduce the lock
    contention.  The batched pages will be added into zone list when the pool
    is full or page reclaim is trying to drain them.

    For example, in a 4 socket 64 CPU system, create a sparse file and 64
    processes, processes shared map to the file.  Each process read access the
    whole file and then exit.  The process exit will do unmap_vmas() and cause
    a lot of activate_page() call.  In such workload, we saw about 58% total
    time reduction with below patch.  Other workloads with a lot of
    activate_page also benefits a lot too.

    Andrew Morton suggested activate_page() and putback_lru_pages() should
    follow the same path to active pages, but this is hard to implement (see
    commit 7a608572a282a ("Revert "mm: batch activate_page() to reduce lock
    contention")).  On the other hand, do we really need putback_lru_pages()
    to follow the same path?  I tested several FIO/FFSB benchmark (about 20
    scripts for each benchmark) in 3 machines here from 2 sockets to 4
    sockets.  My test doesn't show anything significant with/without below
    patch (there is slight difference but mostly some noise which we found
    even without below patch before).  Below patch basically returns to the
    same as my first post.

    I tested some microbenchmarks:
      case-anon-cow-rand-mt         0.58%
      case-anon-cow-rand           -3.30%
      case-anon-cow-seq-mt         -0.51%
      case-anon-cow-seq            -5.68%
      case-anon-r-rand-mt           0.23%
      case-anon-r-rand              0.81%
      case-anon-r-seq-mt           -0.71%
      case-anon-r-seq              -1.99%
      case-anon-rx-rand-mt          2.11%
      case-anon-rx-seq-mt           3.46%
      case-anon-w-rand-mt          -0.03%
      case-anon-w-rand             -0.50%
      case-anon-w-seq-mt           -1.08%
      case-anon-w-seq              -0.12%
      case-anon-wx-rand-mt         -5.02%
      case-anon-wx-seq-mt          -1.43%
      case-fork                     1.65%
      case-fork-sleep              -0.07%
      case-fork-withmem             1.39%
      case-hugetlb                 -0.59%
      case-lru-file-mmap-read-mt   -0.54%
      case-lru-file-mmap-read       0.61%
      case-lru-file-mmap-read-rand -2.24%
      case-lru-file-readonce       -0.64%
      case-lru-file-readtwice     -11.69%
      case-lru-memcg               -1.35%
      case-mmap-pread-rand-mt       1.88%
      case-mmap-pread-rand        -15.26%
      case-mmap-pread-seq-mt        0.89%
      case-mmap-pread-seq         -69.72%
      case-mmap-xread-rand-mt       0.71%
      case-mmap-xread-seq-mt        0.38%

    The most significent are:
      case-lru-file-readtwice     -11.69%
      case-mmap-pread-rand        -15.26%
      case-mmap-pread-seq         -69.72%

    which use activate_page a lot.  others are basically variations because
    each run has slightly difference.

    In UP case, 'size mm/swap.o'
    before the two patches:
       text    data     bss     dec     hex filename
       6466     896       4    7366    1cc6 mm/swap.o
    after the two patches:
       text    data     bss     dec     hex filename
       6343     896       4    7243    1c4b mm/swap.o

    Signed-off-by: Shaohua Li <shaohua.li@intel.com>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Hiroyuki Kamezawa <kamezawa.hiroyuki@gmail.com>
    Cc: Andi Kleen <andi@firstfloor.org>
    Cc: Minchan Kim <minchan.kim@gmail.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
posix-timers: RCU conversion

    Ben Nagy reported a scalability problem with KVM/QEMU that hit very hard
    a single spinlock (idr_lock) in posix-timers code, on its 48 core
    machine.

    Even on a 16 cpu machine (2x4x2), a single test can show 98% of cpu time
    used in ticket_spin_lock, from lock_timer

    Ref: http://www.spinics.net/lists/kvm/msg51526.html

    Switching to RCU is quite easy, IDR being already RCU ready. idr_lock
    should be locked only for an insert/delete, not a lookup.

    Benchmark on a 2x4x2 machine, 16 processes calling timer_gettime().

    Before :

    real    1m18.669s
    user    0m1.346s
    sys     1m17.180s

    After :

    real    0m3.296s
    user    0m1.366s
    sys     0m1.926s

    Reported-by: Ben Nagy <ben@iagu.net>
    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Tested-by: Ben Nagy <ben@iagu.net>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Avi Kivity <avi@redhat.com>
    Cc: John Stultz <johnstul@us.ibm.com>
    Cc: Richard Cochran <richard.cochran@omicron.at>
    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

    Conflicts:

    	include/linux/posix-timers.h
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>
rcu-tree: Check for extended quiescent state at start of gp

During a cpu_hotplug event, it is much more likely for a cpu to be in
extended quiescent state. For example, on cpu_up, tasks are not yet
schedulable on the cpu that is coming up, so that cpu will not context
switch.  Additionally, cpu_down occurs on our dual-core system when
there is not a heavy load on the cpus, which means the cpus are less
likely to context switch. Checking for extended quiescent state at the
beginning of the grace period decreases the hotplug latency because the
rcu process does not necessarily have to wait tens of milliseconds to
force a quiescent state.

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

Change-Id: I73063c4065395782cc2750db3086666f3474f9a4
Signed-off-by: Swetha Basineni <sbasin@codeaurora.org>
sched: Do not block when waiting to free old root domain

Instead of calling synchronize_sched(), directly invoke
call_rcu_sched() which will not block the cpu hotplug
operation but will call free_rootdomain when the rcu
process is complete. This is safe because the root
domains are allocated dynamically so any new readers
will have pointers to the new data and the new data
does not overwrite the old data.

This is a partial backport from 3.0.0 kernel.
I did not backport the dynamic allocation of the sched
domain and sched group data structures.  This would
require inclusion of 10 other patches and would not be
stable.

dce840a08702bd13a9a186e07e63d1ef82256b5e
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Thu Apr 7 14:09:50 2011 +0200

    sched: Dynamically allocate sched_domain/sched_group data-structures

    Instead of relying on static allocations for the sched_domain and
    sched_group trees, dynamically allocate and RCU free them.

    Allocating this dynamically also allows for some build_sched_groups()
    simplification since we can now (like with other simplifications) rely
    on the sched_domain tree instead of hard-coded knowledge.

    One tricky to note is that detach_destroy_domains() needs to hold
    rcu_read_lock() over the entire tear-down, per-cpu is not sufficient
    since that can lead to partial sched_group existance (could possibly
    be solved by doing the tear-down backwards but this is much more
    robust).

    A concequence of the above is that we can no longer print the
    sched_domain debug stuff from cpu_attach_domain() since that might now
    run with preemption disabled (due to classic RCU etc.) and
    sched_domain_debug() does some GFP_KERNEL allocations.

    Another thing to note is that we now fully rely on normal RCU and not
    RCU-sched, this is because with the new and exiting RCU flavours we
    grew over the years BH doesn't necessarily hold off RCU-sched grace
    periods (-rt is known to break this). This would in fact already cause
    us grief since we do sched_domain/sched_group iterations from softirq
    context.

    This patch is somewhat larger than I would like it to be, but I didn't
    find any means of shrinking/splitting this.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Nick Piggin <npiggin@kernel.dk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
    Link: http://lkml.kernel.org/r/20110407122942.245307941@chello.nl
Signed-off-by: Ingo Molnar <mingo@elte.hu>

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

Change-Id: I7305af949900919f06cf3444daf1183370aa07b7
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>