1. 25 6月, 2010 1 次提交
  2. 18 6月, 2010 1 次提交
    • A
      sched: Fix over-scheduling bug · 3c93717c
      Alex,Shi 提交于
      Commit e7097159 ("sched: Optimize unused cgroup configuration") introduced
      an imbalanced scheduling bug.
      
      If we do not use CGROUP, function update_h_load won't update h_load. When the
      system has a large number of tasks far more than logical CPU number, the
      incorrect cfs_rq[cpu]->h_load value will cause load_balance() to pull too
      many tasks to the local CPU from the busiest CPU. So the busiest CPU keeps
      going in a round robin. That will hurt performance.
      
      The issue was found originally by a scientific calculation workload that
      developed by Yanmin. With that commit, the workload performance drops
      about 40%.
      
       CPU  before    after
      
       00   : 2       : 7
       01   : 1       : 7
       02   : 11      : 6
       03   : 12      : 7
       04   : 6       : 6
       05   : 11      : 7
       06   : 10      : 6
       07   : 12      : 7
       08   : 11      : 6
       09   : 12      : 6
       10   : 1       : 6
       11   : 1       : 6
       12   : 6       : 6
       13   : 2       : 6
       14   : 2       : 6
       15   : 1       : 6
      Reviewed-by: NYanmin zhang <yanmin.zhang@intel.com>
      Signed-off-by: NAlex Shi <alex.shi@intel.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1276754893.9452.5442.camel@debian>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3c93717c
  3. 09 6月, 2010 1 次提交
    • P
      sched: Fix PROVE_RCU vs cpu_cgroup · dc61b1d6
      Peter Zijlstra 提交于
      PROVE_RCU has a few issues with the cpu_cgroup because the scheduler
      typically holds rq->lock around the css rcu derefs but the generic
      cgroup code doesn't (and can't) know about that lock.
      
      Provide means to add extra checks to the css dereference and use that
      in the scheduler to annotate its users.
      
      The addition of rq->lock to these checks is correct because the
      cgroup_subsys::attach() method takes the rq->lock for each task it
      moves, therefore by holding that lock, we ensure the task is pinned to
      the current cgroup and the RCU derefence is valid.
      
      That leaves one genuine race in __sched_setscheduler() where we used
      task_group() without holding any of the required locks and thus raced
      with the cgroup code. Solve this by moving the check under the
      appropriate lock.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      dc61b1d6
  4. 05 6月, 2010 11 次提交
    • R
      module: fix bne2 "gave up waiting for init of module libcrc32c" · 9bea7f23
      Rusty Russell 提交于
      Problem: it's hard to avoid an init routine stumbling over a
      request_module these days.  And it's not clear it's always a bad idea:
      for example, a module like kvm with dynamic dependencies on kvm-intel
      or kvm-amd would be neater if it could simply request_module the right
      one.
      
      In this particular case, it's libcrc32c:
      
      	libcrc32c_mod_init
      	 crypto_alloc_shash
      	  crypto_alloc_tfm
      	   crypto_find_alg
      	    crypto_alg_mod_lookup
      	     crypto_larval_lookup
      	      request_module
      
      If another module is waiting inside resolve_symbol() for libcrc32c to
      finish initializing (ie. bne2 depends on libcrc32c) then it does so
      holding the module lock, and our request_module() can't make progress
      until that is released.
      
      Waiting inside resolve_symbol() without the lock isn't all that hard:
      we just need to pass the -EBUSY up the call chain so we can sleep
      where we don't hold the lock.  Error reporting is a bit trickier: we
      need to copy the name of the unfinished module before releasing the
      lock.
      
      Other notes:
      1) This also fixes a theoretical issue where a weak dependency would allow
         symbol version mismatches to be ignored.
      2) We rename use_module to ref_module to make life easier for the only
         external user (the out-of-tree ksplice patches).
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Tim Abbot <tabbott@ksplice.com>
      Tested-by: NBrandon Philips <bphilips@suse.de>
      9bea7f23
    • R
      module: verify_export_symbols under the lock · be593f4c
      Rusty Russell 提交于
      It disabled preempt so it was "safe", but nothing stops another module
      slipping in before this module is added to the global list now we don't
      hold the lock the whole time.
      
      So we check this just after we check for duplicate modules, and just
      before we put the module in the global list.
      
      (find_symbol finds symbols in coming and going modules, too).
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      be593f4c
    • L
      module: move find_module check to end · 3bafeb62
      Linus Torvalds 提交于
      I think Rusty may have made the lock a bit _too_ finegrained there, and
      didn't add it to some places that needed it. It looks, for example, like
      PATCH 1/2 actually drops the lock in places where it's needed
      ("find_module()" is documented to need it, but now load_module() didn't
      hold it at all when it did the find_module()).
      
      Rather than adding a new "module_loading" list, I think we should be able
      to just use the existing "modules" list, and just fix up the locking a
      bit.
      
      In fact, maybe we could just move the "look up existing module" a bit
      later - optimistically assuming that the module doesn't exist, and then
      just undoing the work if it turns out that we were wrong, just before
      adding ourselves to the list.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      3bafeb62
    • R
      module: make locking more fine-grained. · 75676500
      Rusty Russell 提交于
      Kay Sievers <kay.sievers@vrfy.org> reports that we still have some
      contention over module loading which is slowing boot.
      
      Linus also disliked a previous "drop lock and regrab" patch to fix the
      bne2 "gave up waiting for init of module libcrc32c" message.
      
      This is more ambitious: we only grab the lock where we need it.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Brandon Philips <brandon@ifup.org>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      75676500
    • R
      module: Make module sysfs functions private. · 6407ebb2
      Rusty Russell 提交于
      These were placed in the header in ef665c1a to get the various
      SYSFS/MODULE config combintations to compile.
      
      That may have been necessary then, but it's not now.  These functions
      are all local to module.c.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      6407ebb2
    • R
      module: move sysfs exposure to end of load_module · 80a3d1bb
      Rusty Russell 提交于
      This means a little extra work, but is more logical: we don't put
      anything in sysfs until we're about to put the module into the
      global list an parse its parameters.
      
      This also gives us a logical place to put duplicate module detection
      in the next patch.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      80a3d1bb
    • R
      module: fix kdb's illicit use of struct module_use. · c8e21ced
      Rusty Russell 提交于
      Linus changed the structure, and luckily this didn't compile any more.
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Cc: Martin Hicks <mort@sgi.com>
      c8e21ced
    • L
      module: Make the 'usage' lists be two-way · 2c02dfe7
      Linus Torvalds 提交于
      When adding a module that depends on another one, we used to create a
      one-way list of "modules_which_use_me", so that module unloading could
      see who needs a module.
      
      It's actually quite simple to make that list go both ways: so that we
      not only can see "who uses me", but also see a list of modules that are
      "used by me".
      
      In fact, we always wanted that list in "module_unload_free()": when we
      unload a module, we want to also release all the other modules that are
      used by that module.  But because we didn't have that list, we used to
      first iterate over all modules, and then iterate over each "used by me"
      list of that module.
      
      By making the list two-way, we simplify module_unload_free(), and it
      allows for some trivial fixes later too.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (cleaned & rebased)
      2c02dfe7
    • A
      kernel/: fix BUG_ON checks for cpu notifier callbacks direct call · 9e506f7a
      Akinobu Mita 提交于
      The commit 80b5184c ("kernel/: convert cpu
      notifier to return encapsulate errno value") changed the return value of
      cpu notifier callbacks.
      
      Those callbacks don't return NOTIFY_BAD on failures anymore.  But there
      are a few callbacks which are called directly at init time and checking
      the return value.
      
      I forgot to change BUG_ON checking by the direct callers in the commit.
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9e506f7a
    • G
      cgroups: alloc_css_id() increments hierarchy depth · 94b3dd0f
      Greg Thelen 提交于
      Child groups should have a greater depth than their parents.  Prior to
      this change, the parent would incorrectly report zero memory usage for
      child cgroups when use_hierarchy is enabled.
      
      test script:
        mount -t cgroup none /cgroups -o memory
        cd /cgroups
        mkdir cg1
      
        echo 1 > cg1/memory.use_hierarchy
        mkdir cg1/cg11
      
        echo $$ > cg1/cg11/tasks
        dd if=/dev/zero of=/tmp/foo bs=1M count=1
      
        echo
        echo CHILD
        grep cache cg1/cg11/memory.stat
      
        echo
        echo PARENT
        grep cache cg1/memory.stat
      
        echo $$ > tasks
        rmdir cg1/cg11 cg1
        cd /
        umount /cgroups
      
      Using fae9c791, a recent patch that changed alloc_css_id() depth computation,
      the parent incorrectly reports zero usage:
        root@ubuntu:~# ./test
        1+0 records in
        1+0 records out
        1048576 bytes (1.0 MB) copied, 0.0151844 s, 69.1 MB/s
      
        CHILD
        cache 1048576
        total_cache 1048576
      
        PARENT
        cache 0
        total_cache 0
      
      With this patch, the parent correctly includes child usage:
        root@ubuntu:~# ./test
        1+0 records in
        1+0 records out
        1048576 bytes (1.0 MB) copied, 0.0136827 s, 76.6 MB/s
      
        CHILD
        cache 1052672
        total_cache 1052672
      
        PARENT
        cache 0
        total_cache 1052672
      Signed-off-by: NGreg Thelen <gthelen@google.com>
      Acked-by: NPaul Menage <menage@google.com>
      Acked-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Acked-by: NLi Zefan <lizf@cn.fujitsu.com>
      Cc: <stable@kernel.org>		[2.6.34.x]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      94b3dd0f
    • O
      sys_personality: change sys_personality() to accept "unsigned int" instead of u_long · 485d5276
      Oleg Nesterov 提交于
      task_struct->pesonality is "unsigned int", but sys_personality() paths use
      "unsigned long pesonality".  This means that every assignment or
      comparison is not right.  In particular, if this argument does not fit
      into "unsigned int" __set_personality() changes the caller's personality
      and then sys_personality() returns -EINVAL.
      
      Turn this argument into "unsigned int" and avoid overflows.  Obviously,
      this is the user-visible change, we just ignore the upper bits.  But this
      can't break the sane application.
      
      There is another thing which can confuse the poorly written applications.
      User-space thinks that this syscall returns int, not long.  This means
      that the returned value can be negative and look like the error code.  But
      note that libc won't be confused and thus errno won't be set, and with
      this patch the user-space can never get -1 unless sys_personality() really
      fails.  And, most importantly, the negative RET != -1 is only possible if
      that app previously called personality(RET).
      Pointed-out-by: NWenming Zhang <wezhang@redhat.com>
      Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      485d5276
  5. 03 6月, 2010 2 次提交
  6. 02 6月, 2010 1 次提交
  7. 01 6月, 2010 2 次提交
  8. 31 5月, 2010 10 次提交
  9. 30 5月, 2010 1 次提交
  10. 28 5月, 2010 10 次提交