1. 27 Jul, 2011 15 commits
    • Chris Mason's avatar
      Merge branch 'integration' into for-linus · ff95acb6
      Chris Mason authored
      ff95acb6
    • Chris Mason's avatar
      Btrfs: make sure reserve_metadata_bytes doesn't leak out strange errors · 75c195a2
      Chris Mason authored
      The btrfs transaction code will return any errors that come from
      reserve_metadata_bytes.  We need to make sure we don't return funny
      things like 1 or EAGAIN.
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      75c195a2
    • Chris Mason's avatar
      Btrfs: use the commit_root for reading free_space_inode crcs · 2cf8572d
      Chris Mason authored
      Now that we are using regular file crcs for the free space cache,
      we can deadlock if we try to read the free_space_inode while we are
      updating the crc tree.
      
      This commit fixes things by using the commit_root to read the crcs.  This is
      safe because we the free space cache file would already be loaded if
      that block group had been changed in the current transaction.
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      2cf8572d
    • Chris Mason's avatar
      Btrfs: reduce extent_state lock contention for metadata · 19b6caf4
      Chris Mason authored
      For metadata buffers that don't straddle pages (all of them), btrfs
      can safely use the page uptodate bits and extent_buffer uptodate bit
      instead of needing to use the extent_state tree.
      
      This greatly reduces contention on the state tree lock.
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      19b6caf4
    • Chris Mason's avatar
      Btrfs: remove lockdep magic from btrfs_next_leaf · 31533fb2
      Chris Mason authored
      Before the reader/writer locks, btrfs_next_leaf needed to keep
      the path blocking to avoid making lockdep upset.
      
      Now that btrfs_next_leaf only takes read locks, this isn't required.
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      31533fb2
    • Chris Mason's avatar
      Btrfs: make a lockdep class for each root · 85d4e461
      Chris Mason authored
      This patch was originally from Tejun Heo.  lockdep complains about the btrfs
      locking because we sometimes take btree locks from two different trees at the
      same time.  The current classes are based only on level in the btree, which
      isn't enough information for lockdep to figure out if the lock is safe.
      
      This patch makes a class for each type of tree, and lumps all the FS trees that
      actually have files and directories into the same class.
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      85d4e461
    • Chris Mason's avatar
      Btrfs: switch the btrfs tree locks to reader/writer · bd681513
      Chris Mason authored
      The btrfs metadata btree is the source of significant
      lock contention, especially in the root node.   This
      commit changes our locking to use a reader/writer
      lock.
      
      The lock is built on top of rw spinlocks, and it
      extends the lock tracking to remember if we have a
      read lock or a write lock when we go to blocking.  Atomics
      count the number of blocking readers or writers at any
      given time.
      
      It removes all of the adaptive spinning from the old code
      and uses only the spinning/blocking hints inside of btrfs
      to decide when it should continue spinning.
      
      In read heavy workloads this is dramatically faster.  In write
      heavy workloads we're still faster because of less contention
      on the root node lock.
      
      We suffer slightly in dbench because we schedule more often
      during write locks, but all other benchmarks so far are improved.
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      bd681513
    • Josef Bacik's avatar
      Btrfs: fix deadlock when throttling transactions · 81317fde
      Josef Bacik authored
      Hit this nice little deadlock.  What happens is this
      
      __btrfs_end_transaction with throttle set, --use_count so it equals 0
        btrfs_commit_transaction
          <somebody else actually manages to start the commit>
          btrfs_end_transaction --use_count so now its -1 <== BAD
            we just return and wait on the transaction
      
      This is bad because we just return after our use_count is -1 and don't let go
      of our num_writer count on the transaction, so the guy committing the
      transaction just sits there forever.  Fix this by inc'ing our use_count if we're
      going to call commit_transaction so that if we call btrfs_end_transaction it's
      valid.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      81317fde
    • Chris Mason's avatar
      Btrfs: stop using highmem for extent_buffers · a6591715
      Chris Mason authored
      The extent_buffers have a very complex interface where
      we use HIGHMEM for metadata and try to cache a kmap mapping
      to access the memory.
      
      The next commit adds reader/writer locks, and concurrent use
      of this kmap cache would make it even more complex.
      
      This commit drops the ability to use HIGHMEM with extent buffers,
      and rips out all of the related code.
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      a6591715
    • Miao Xie's avatar
      Btrfs: fix BUG_ON() caused by ENOSPC when relocating space · 199c36ea
      Miao Xie authored
      When we balanced the chunks across the devices, BUG_ON() in
      __finish_chunk_alloc() was triggered.
      
      ------------[ cut here ]------------
      kernel BUG at fs/btrfs/volumes.c:2568!
      [SNIP]
      Call Trace:
       [<ffffffffa049525e>] btrfs_alloc_chunk+0x8e/0xa0 [btrfs]
       [<ffffffffa04546b0>] do_chunk_alloc+0x330/0x3a0 [btrfs]
       [<ffffffffa045c654>] btrfs_reserve_extent+0xb4/0x1f0 [btrfs]
       [<ffffffffa045c86b>] btrfs_alloc_free_block+0xdb/0x350 [btrfs]
       [<ffffffffa048a8d8>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
       [<ffffffffa04476fd>] __btrfs_cow_block+0x14d/0x5e0 [btrfs]
       [<ffffffffa044660d>] ? read_block_for_search+0x14d/0x4d0 [btrfs]
       [<ffffffffa0447c9b>] btrfs_cow_block+0x10b/0x240 [btrfs]
       [<ffffffffa044dd5e>] btrfs_search_slot+0x49e/0x7a0 [btrfs]
       [<ffffffffa044f07d>] btrfs_insert_empty_items+0x8d/0xf0 [btrfs]
       [<ffffffffa045e973>] insert_with_overflow+0x43/0x110 [btrfs]
       [<ffffffffa045eb0d>] btrfs_insert_dir_item+0xcd/0x1f0 [btrfs]
       [<ffffffffa0489bd0>] ? map_extent_buffer+0xb0/0xc0 [btrfs]
       [<ffffffff812276ad>] ? rb_insert_color+0x9d/0x160
       [<ffffffffa046cc40>] ? inode_tree_add+0xf0/0x150 [btrfs]
       [<ffffffffa0474801>] btrfs_add_link+0xc1/0x1c0 [btrfs]
       [<ffffffff811dacac>] ? security_inode_init_security+0x1c/0x30
       [<ffffffffa04a28aa>] ? btrfs_init_acl+0x4a/0x180 [btrfs]
       [<ffffffffa047492f>] btrfs_add_nondir+0x2f/0x70 [btrfs]
       [<ffffffffa046af16>] ? btrfs_init_inode_security+0x46/0x60 [btrfs]
       [<ffffffffa0474ac0>] btrfs_create+0x150/0x1d0 [btrfs]
       [<ffffffff81159c63>] ? generic_permission+0x23/0xb0
       [<ffffffff8115b415>] vfs_create+0xa5/0xc0
       [<ffffffff8115ce6e>] do_last+0x5fe/0x880
       [<ffffffff8115dc0d>] path_openat+0xcd/0x3d0
       [<ffffffff8115e029>] do_filp_open+0x49/0xa0
       [<ffffffff8116a965>] ? alloc_fd+0x95/0x160
       [<ffffffff8114f0c7>] do_sys_open+0x107/0x1e0
       [<ffffffff810bcc3f>] ? audit_syscall_entry+0x1bf/0x1f0
       [<ffffffff8114f1e0>] sys_open+0x20/0x30
       [<ffffffff81484ec2>] system_call_fastpath+0x16/0x1b
      [SNIP]
      RIP  [<ffffffffa049444a>] __finish_chunk_alloc+0x20a/0x220 [btrfs]
      
      The reason is:
      Task1					Space balance task
      do_chunk_alloc()
        __finish_chunk_alloc()
          update device info
          in the chunk tree
            alloc system metadata block
      					relocate system metadata block group
      					  set system metadata block group
      					  readonly, This block group is the
      					  only one that can allocate space. So
      					  there is no free space that can be
      					  allocated now.
              find no space and don't try
              to alloc new chunk, and then
              return ENOSPC
        BUG_ON() in __finish_chunk_alloc()
        was triggered.
      
      Fix this bug by allocating a new system metadata chunk before relocating the
      old one if we find there is no free space which can be allocated after setting
      the old block group to be read-only.
      Reported-by: default avatarTsutomu Itoh <t-itoh@jp.fujitsu.com>
      Signed-off-by: default avatarMiao Xie <miaox@cn.fujitsu.com>
      Tested-by: default avatarTsutomu Itoh <t-itoh@jp.fujitsu.com>
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      199c36ea
    • Josef Bacik's avatar
      Btrfs: tag pages for writeback in sync · f7aaa06b
      Josef Bacik authored
      Everybody else does this, we need to do it too.  If we're syncing, we need to
      tag the pages we're going to write for writeback so we don't end up writing the
      same stuff over and over again if somebody is constantly redirtying our file.
      This will keep us from having latencies with heavy sync workloads.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      f7aaa06b
    • Josef Bacik's avatar
      Btrfs: fix enospc problems with delalloc · 9e0baf60
      Josef Bacik authored
      So I had this brilliant idea to use atomic counters for outstanding and reserved
      extents, but this turned out to be a bad idea.  Consider this where we have 1
      outstanding extent and 1 reserved extent
      
      Reserver				Releaser
      					atomic_dec(outstanding) now 0
      atomic_read(outstanding)+1 get 1
      atomic_read(reserved) get 1
      don't actually reserve anything because
      they are the same
      					atomic_cmpxchg(reserved, 1, 0)
      atomic_inc(outstanding)
      atomic_add(0, reserved)
      					free reserved space for 1 extent
      
      Then the reserver now has no actual space reserved for it, and when it goes to
      finish the ordered IO it won't have enough space to do it's allocation and you
      get those lovely warnings.
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      9e0baf60
    • Josef Bacik's avatar
      Btrfs: don't flush delalloc arbitrarily · a5991428
      Josef Bacik authored
      Kill the check to see if we have 512mb of reserved space in delalloc and
      shrink_delalloc if we do.  This causes unexpected latencies and we have other
      logic to see if we need to throttle.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      a5991428
    • Josef Bacik's avatar
      Btrfs: use find_or_create_page instead of grab_cache_page · a94733d0
      Josef Bacik authored
      grab_cache_page will use mapping_gfp_mask(), which for all inodes is set to
      GFP_HIGHUSER_MOVABLE.  So instead use find_or_create_page in all cases where we
      need GFP_NOFS so we don't deadlock.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      a94733d0
    • Josef Bacik's avatar
      Btrfs: use a worker thread to do caching · bab39bf9
      Josef Bacik authored
      A user reported a deadlock when copying a bunch of files.  This is because they
      were low on memory and kthreadd got hung up trying to migrate pages for an
      allocation when starting the caching kthread.  The page was locked by the person
      starting the caching kthread.  To fix this we just need to use the async thread
      stuff so that the threads are already created and we don't have to worry about
      deadlocks.  Thanks,
      Reported-by: default avatarRoman Mamedov <rm@romanrm.ru>
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      bab39bf9
  2. 22 Jul, 2011 2 commits
  3. 21 Jul, 2011 9 commits
  4. 20 Jul, 2011 14 commits
    • Linus Torvalds's avatar
      Merge branch 'core-urgent-for-linus' of... · cf6ace16
      Linus Torvalds authored
      Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        signal: align __lock_task_sighand() irq disabling and RCU
        softirq,rcu: Inform RCU of irq_exit() activity
        sched: Add irq_{enter,exit}() to scheduler_ipi()
        rcu: protect __rcu_read_unlock() against scheduler-using irq handlers
        rcu: Streamline code produced by __rcu_read_unlock()
        rcu: Fix RCU_BOOST race handling current->rcu_read_unlock_special
        rcu: decrease rcu_report_exp_rnp coupling with scheduler
      cf6ace16
    • Linus Torvalds's avatar
      Merge branch 'sched-urgent-for-linus' of... · acc11eab
      Linus Torvalds authored
      Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        sched: Avoid creating superfluous NUMA domains on non-NUMA systems
        sched: Allow for overlapping sched_domain spans
        sched: Break out cpu_power from the sched_group structure
      acc11eab
    • Linus Torvalds's avatar
      Merge branch 'x86-urgent-for-linus' of... · 919d25a7
      Linus Torvalds authored
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        x86. reboot: Make Dell Latitude E6320 use reboot=pci
        x86, doc only: Correct real-mode kernel header offset for init_size
        x86: Disable AMD_NUMA for 32bit for now
      919d25a7
    • Ingo Molnar's avatar
      Merge branch 'rcu/urgent' of... · d1e9ae47
      Ingo Molnar authored
      Merge branch 'rcu/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-2.6-rcu into core/urgent
      d1e9ae47
    • Paul E. McKenney's avatar
      signal: align __lock_task_sighand() irq disabling and RCU · a841796f
      Paul E. McKenney authored
      The __lock_task_sighand() function calls rcu_read_lock() with interrupts
      and preemption enabled, but later calls rcu_read_unlock() with interrupts
      disabled.  It is therefore possible that this RCU read-side critical
      section will be preempted and later RCU priority boosted, which means that
      rcu_read_unlock() will call rt_mutex_unlock() in order to deboost itself, but
      with interrupts disabled. This results in lockdep splats, so this commit
      nests the RCU read-side critical section within the interrupt-disabled
      region of code.  This prevents the RCU read-side critical section from
      being preempted, and thus prevents the attempt to deboost with interrupts
      disabled.
      
      It is quite possible that a better long-term fix is to make rt_mutex_unlock()
      disable irqs when acquiring the rt_mutex structure's ->wait_lock.
      Signed-off-by: default avatarPaul E. McKenney <paul.mckenney@linaro.org>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      a841796f
    • Peter Zijlstra's avatar
      softirq,rcu: Inform RCU of irq_exit() activity · ec433f0c
      Peter Zijlstra authored
      The rcu_read_unlock_special() function relies on in_irq() to exclude
      scheduler activity from interrupt level.  This fails because exit_irq()
      can invoke the scheduler after clearing the preempt_count() bits that
      in_irq() uses to determine that it is at interrupt level.  This situation
      can result in failures as follows:
      
       $task			IRQ		SoftIRQ
      
       rcu_read_lock()
      
       /* do stuff */
      
       <preempt> |= UNLOCK_BLOCKED
      
       rcu_read_unlock()
         --t->rcu_read_lock_nesting
      
      			irq_enter();
      			/* do stuff, don't use RCU */
      			irq_exit();
      			  sub_preempt_count(IRQ_EXIT_OFFSET);
      			  invoke_softirq()
      
      					ttwu();
      					  spin_lock_irq(&pi->lock)
      					  rcu_read_lock();
      					  /* do stuff */
      					  rcu_read_unlock();
      					    rcu_read_unlock_special()
      					      rcu_report_exp_rnp()
      					        ttwu()
      					          spin_lock_irq(&pi->lock) /* deadlock */
      
         rcu_read_unlock_special(t);
      
      Ed can simply trigger this 'easy' because invoke_softirq() immediately
      does a ttwu() of ksoftirqd/# instead of doing the in-place softirq stuff
      first, but even without that the above happens.
      
      Cure this by also excluding softirqs from the
      rcu_read_unlock_special() handler and ensuring the force_irqthreads
      ksoftirqd/# wakeup is done from full softirq context.
      
      [ Alternatively, delaying the ->rcu_read_lock_nesting decrement
        until after the special handling would make the thing more robust
        in the face of interrupts as well.  And there is a separate patch
        for that. ]
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Reported-and-tested-by: default avatarEd Tomlinson <edt@aei.ca>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      ec433f0c
    • Peter Zijlstra's avatar
      sched: Add irq_{enter,exit}() to scheduler_ipi() · c5d753a5
      Peter Zijlstra authored
      Ensure scheduler_ipi() calls irq_{enter,exit} when it does some actual
      work. Traditionally we never did any actual work from the resched IPI
      and all magic happened in the return from interrupt path.
      
      Now that we do do some work, we need to ensure irq_{enter,exit} are
      called so that we don't confuse things.
      
      This affects things like timekeeping, NO_HZ and RCU, basically
      everything with a hook in irq_enter/exit.
      
      Explicit examples of things going wrong are:
      
        sched_clock_cpu() -- has a callback when leaving NO_HZ state to take
                          a new reading from GTOD and TSC. Without this
                          callback, time is stuck in the past.
      
        RCU -- needs in_irq() to work in order to avoid some nasty deadlocks
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      c5d753a5
    • Paul E. McKenney's avatar
      rcu: protect __rcu_read_unlock() against scheduler-using irq handlers · 10f39bb1
      Paul E. McKenney authored
      The addition of RCU read-side critical sections within runqueue and
      priority-inheritance lock critical sections introduced some deadlock
      cycles, for example, involving interrupts from __rcu_read_unlock()
      where the interrupt handlers call wake_up().  This situation can cause
      the instance of __rcu_read_unlock() invoked from interrupt to do some
      of the processing that would otherwise have been carried out by the
      task-level instance of __rcu_read_unlock().  When the interrupt-level
      instance of __rcu_read_unlock() is called with a scheduler lock held
      from interrupt-entry/exit situations where in_irq() returns false,
      deadlock can result.
      
      This commit resolves these deadlocks by using negative values of
      the per-task ->rcu_read_lock_nesting counter to indicate that an
      instance of __rcu_read_unlock() is in flight, which in turn prevents
      instances from interrupt handlers from doing any special processing.
      This patch is inspired by Steven Rostedt's earlier patch that similarly
      made __rcu_read_unlock() guard against interrupt-mediated recursion
      (see https://lkml.org/lkml/2011/7/15/326), but this commit refines
      Steven's approach to avoid the need for preemption disabling on the
      __rcu_read_unlock() fastpath and to also avoid the need for manipulating
      a separate per-CPU variable.
      
      This patch avoids need for preempt_disable() by instead using negative
      values of the per-task ->rcu_read_lock_nesting counter.  Note that nested
      rcu_read_lock()/rcu_read_unlock() pairs are still permitted, but they will
      never see ->rcu_read_lock_nesting go to zero, and will therefore never
      invoke rcu_read_unlock_special(), thus preventing them from seeing the
      RCU_READ_UNLOCK_BLOCKED bit should it be set in ->rcu_read_unlock_special.
      This patch also adds a check for ->rcu_read_unlock_special being negative
      in rcu_check_callbacks(), thus preventing the RCU_READ_UNLOCK_NEED_QS
      bit from being set should a scheduling-clock interrupt occur while
      __rcu_read_unlock() is exiting from an outermost RCU read-side critical
      section.
      
      Of course, __rcu_read_unlock() can be preempted during the time that
      ->rcu_read_lock_nesting is negative.  This could result in the setting
      of the RCU_READ_UNLOCK_BLOCKED bit after __rcu_read_unlock() checks it,
      and would also result it this task being queued on the corresponding
      rcu_node structure's blkd_tasks list.  Therefore, some later RCU read-side
      critical section would enter rcu_read_unlock_special() to clean up --
      which could result in deadlock if that critical section happened to be in
      the scheduler where the runqueue or priority-inheritance locks were held.
      
      This situation is dealt with by making rcu_preempt_note_context_switch()
      check for negative ->rcu_read_lock_nesting, thus refraining from
      queuing the task (and from setting RCU_READ_UNLOCK_BLOCKED) if we are
      already exiting from the outermost RCU read-side critical section (in
      other words, we really are no longer actually in that RCU read-side
      critical section).  In addition, rcu_preempt_note_context_switch()
      invokes rcu_read_unlock_special() to carry out the cleanup in this case,
      which clears out the ->rcu_read_unlock_special bits and dequeues the task
      (if necessary), in turn avoiding needless delay of the current RCU grace
      period and needless RCU priority boosting.
      
      It is still illegal to call rcu_read_unlock() while holding a scheduler
      lock if the prior RCU read-side critical section has ever had either
      preemption or irqs enabled.  However, the common use case is legal,
      namely where then entire RCU read-side critical section executes with
      irqs disabled, for example, when the scheduler lock is held across the
      entire lifetime of the RCU read-side critical section.
      Signed-off-by: default avatarPaul E. McKenney <paul.mckenney@linaro.org>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      10f39bb1
    • Peter Zijlstra's avatar
      sched: Avoid creating superfluous NUMA domains on non-NUMA systems · d110235d
      Peter Zijlstra authored
      When creating sched_domains, stop when we've covered the entire
      target span instead of continuing to create domains, only to
      later find they're redundant and throw them away again.
      
      This avoids single node systems from touching funny NUMA
      sched_domain creation code and reduces the risks of the new
      SD_OVERLAP code.
      Requested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: mahesh@linux.vnet.ibm.com
      Cc: benh@kernel.crashing.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Link: http://lkml.kernel.org/r/1311180177.29152.57.camel@twinsSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
      d110235d
    • Peter Zijlstra's avatar
      sched: Allow for overlapping sched_domain spans · e3589f6c
      Peter Zijlstra authored
      Allow for sched_domain spans that overlap by giving such domains their
      own sched_group list instead of sharing the sched_groups amongst
      each-other.
      
      This is needed for machines with more than 16 nodes, because
      sched_domain_node_span() will generate a node mask from the
      16 nearest nodes without regard if these masks have any overlap.
      
      Currently sched_domains have a sched_group that maps to their child
      sched_domain span, and since there is no overlap we share the
      sched_group between the sched_domains of the various CPUs. If however
      there is overlap, we would need to link the sched_group list in
      different ways for each cpu, and hence sharing isn't possible.
      
      In order to solve this, allocate private sched_groups for each CPU's
      sched_domain but have the sched_groups share a sched_group_power
      structure such that we can uniquely track the power.
      Reported-and-tested-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/n/tip-08bxqw9wis3qti9u5inifh3y@git.kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e3589f6c
    • Peter Zijlstra's avatar
      sched: Break out cpu_power from the sched_group structure · 9c3f75cb
      Peter Zijlstra authored
      In order to prepare for non-unique sched_groups per domain, we need to
      carry the cpu_power elsewhere, so put a level of indirection in.
      Reported-and-tested-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/n/tip-qkho2byuhe4482fuknss40ad@git.kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
      9c3f75cb
    • Linus Torvalds's avatar
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/linux-arm-soc · 47126d80
      Linus Torvalds authored
      * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/linux-arm-soc:
        davinci: DM365 EVM: fix video input mux bits
        ARM: davinci: Check for NULL return from irq_alloc_generic_chip
        arm: davinci: Fix low level gpio irq handlers' argument
      47126d80
    • Shaohua Li's avatar
      vmscan: fix a livelock in kswapd · 4746efde
      Shaohua Li authored
      I'm running a workload which triggers a lot of swap in a machine with 4
      nodes.  After I kill the workload, I found a kswapd livelock.  Sometimes
      kswapd3 or kswapd2 are keeping running and I can't access filesystem,
      but most memory is free.
      
      This looks like a regression since commit 08951e54 ("mm: vmscan:
      correct check for kswapd sleeping in sleeping_prematurely").
      
      Node 2 and 3 have only ZONE_NORMAL, but balance_pgdat() will return 0
      for classzone_idx.  The reason is end_zone in balance_pgdat() is 0 by
      default, if all zones have watermark ok, end_zone will keep 0.
      
      Later sleeping_prematurely() always returns true.  Because this is an
      order 3 wakeup, and if classzone_idx is 0, both balanced_pages and
      present_pages in pgdat_balanced() are 0.  We add a special case here.
      If a zone has no page, we think it's balanced.  This fixes the livelock.
      Signed-off-by: default avatarShaohua Li <shaohua.li@intel.com>
      Acked-by: default avatarMel Gorman <mgorman@suse.de>
      Cc: Minchan Kim <minchan.kim@gmail.com>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4746efde