1. 16 10月, 2008 1 次提交
  2. 09 10月, 2008 1 次提交
    • I
      sched debug: add name to sched_domain sysctl entries · a5d8c348
      Ingo Molnar 提交于
      add /proc/sys/kernel/sched_domain/cpu0/domain0/name, to make
      it easier to see which specific scheduler domain remained at
      that entry.
      
      Since we process the scheduler domain tree and
      simplify it, it's not always immediately clear during debugging
      which domain came from where.
      
      depends on CONFIG_SCHED_DEBUG=y.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a5d8c348
  3. 06 10月, 2008 1 次提交
  4. 29 9月, 2008 1 次提交
    • T
      hrtimer: prevent migration of per CPU hrtimers · ccc7dadf
      Thomas Gleixner 提交于
      Impact: per CPU hrtimers can be migrated from a dead CPU
      
      The hrtimer code has no knowledge about per CPU timers, but we need to
      prevent the migration of such timers and warn when such a timer is
      active at migration time.
      
      Explicitely mark the timers as per CPU and use a more understandable
      mode descriptor for the interrupts safe unlocked callback mode, which
      is used by hrtimer_sleeper and the scheduler code.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      ccc7dadf
  5. 23 9月, 2008 3 次提交
  6. 22 9月, 2008 1 次提交
  7. 11 9月, 2008 1 次提交
    • H
      sched: fix deadlock in setting scheduler parameter to zero · ec5d4989
      Hiroshi Shimamoto 提交于
      Andrei Gusev wrote:
      
      > I played witch scheduler settings. After doing something like:
      > echo -n 1000000 >sched_rt_period_us
      >
      > command is locked. I found in kernel.log:
      >
      > Sep 11 00:39:34 zaratustra
      > Sep 11 00:39:34 zaratustra Pid: 4495, comm: bash Tainted: G        W
      > (2.6.26.3 #12)
      > Sep 11 00:39:34 zaratustra EIP: 0060:[<c0213fc7>] EFLAGS: 00210246 CPU: 0
      > Sep 11 00:39:34 zaratustra EIP is at div64_u64+0x57/0x80
      > Sep 11 00:39:34 zaratustra EAX: 0000389f EBX: 00000000 ECX: 00000000
      > EDX: 00000000
      > Sep 11 00:39:34 zaratustra ESI: d9800000 EDI: d9800000 EBP: 0000389f
      > ESP: ea7a6edc
      > Sep 11 00:39:34 zaratustra DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
      > Sep 11 00:39:34 zaratustra Process bash (pid: 4495, ti=ea7a6000
      > task=ea744000 task.ti=ea7a6000)
      > Sep 11 00:39:34 zaratustra Stack: 00000000 000003e8 d9800000 0000389f
      > c0119042 00000000 00000000 00000001
      > Sep 11 00:39:34 zaratustra 00000000 00000000 ea7a6f54 00010000 00000000
      > c04d2e80 00000001 000e7ef0
      > Sep 11 00:39:34 zaratustra c01191a3 00000000 00000000 ea7a6fa0 00000001
      > ffffffff c04d2e80 ea5b2480
      > Sep 11 00:39:34 zaratustra Call Trace:
      > Sep 11 00:39:34 zaratustra [<c0119042>] __rt_schedulable+0x52/0x130
      > Sep 11 00:39:34 zaratustra [<c01191a3>] sched_rt_handler+0x83/0x120
      > Sep 11 00:39:34 zaratustra [<c01a76a6>] proc_sys_call_handler+0xb6/0xd0
      > Sep 11 00:39:34 zaratustra [<c01a76c0>] proc_sys_write+0x0/0x20
      > Sep 11 00:39:34 zaratustra [<c01a76d9>] proc_sys_write+0x19/0x20
      > Sep 11 00:39:34 zaratustra [<c016cc68>] vfs_write+0xa8/0x140
      > Sep 11 00:39:34 zaratustra [<c016cdd1>] sys_write+0x41/0x80
      > Sep 11 00:39:34 zaratustra [<c0103051>] sysenter_past_esp+0x6a/0x91
      > Sep 11 00:39:34 zaratustra =======================
      > Sep 11 00:39:34 zaratustra Code: c8 41 0f ad f3 d3 ee f6 c1 20 0f 45 de
      > 31 f6 0f ad ef d3 ed f6 c1 20 0f 45 fd 0f 45 ee 31 c9 39 eb 89 fe 89 ea
      > 77 08 89 e8 31 d2 <f7> f3 89 c1 89 f0 8b 7c 24 08 f7 f3 8b 74 24 04 89
      > ca 8b 1c 24
      > Sep 11 00:39:34 zaratustra EIP: [<c0213fc7>] div64_u64+0x57/0x80 SS:ESP
      > 0068:ea7a6edc
      > Sep 11 00:39:34 zaratustra ---[ end trace 4eaa2a86a8e2da22 ]---
      
      fix the boundary condition.
      
      sysctl_sched_rt_period=0 makes exception at to_ratio().
      Signed-off-by: NHiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ec5d4989
  8. 07 9月, 2008 1 次提交
    • M
      sched: arch_reinit_sched_domains() must destroy domains to force rebuild · dfb512ec
      Max Krasnyansky 提交于
      What I realized recently is that calling rebuild_sched_domains() in
      arch_reinit_sched_domains() by itself is not enough when cpusets are enabled.
      partition_sched_domains() code is trying to avoid unnecessary domain rebuilds
      and will not actually rebuild anything if new domain masks match the old ones.
      
      What this means is that doing
           echo 1 > /sys/devices/system/cpu/sched_mc_power_savings
      on a system with cpusets enabled will not take affect untill something changes
      in the cpuset setup (ie new sets created or deleted).
      
      This patch fixes restore correct behaviour where domains must be rebuilt in
      order to enable MC powersaving flags.
      
      Test on quad-core Core2 box with both CONFIG_CPUSETS and !CONFIG_CPUSETS.
      Also tested on dual-core Core2 laptop. Lockdep is happy and things are working
      as expected.
      Signed-off-by: NMax Krasnyansky <maxk@qualcomm.com>
      Tested-by: NVaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      dfb512ec
  9. 06 9月, 2008 2 次提交
    • K
      sched: compilation fix with gcc 3.4.6 · c8bfff6d
      Krzysztof Helt 提交于
      I found that 2.6.27-rc5-mm1 does not compile with gcc 3.4.6.
      The error is:
        CC      kernel/sched.o
      kernel/sched.c: In function `start_rt_bandwidth':
      kernel/sched.c:208: sorry, unimplemented: inlining failed in call to 'rt_bandwidth_enabled': function body not available
      kernel/sched.c:214: sorry, unimplemented: called from here
      make[1]: *** [kernel/sched.o] Error 1
      make: *** [kernel] Error 2
      
      It seems that the gcc 3.4.6 requires full inline definition before first usage.
      The patch below fixes the compilation problem.
      
      Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl> (if needed>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c8bfff6d
    • B
      sched: fix process time monotonicity · 49048622
      Balbir Singh 提交于
      Spencer reported a problem where utime and stime were going negative despite
      the fixes in commit b27f03d4. The suspected
      reason for the problem is that signal_struct maintains it's own utime and
      stime (of exited tasks), these are not updated using the new task_utime()
      routine, hence sig->utime can go backwards and cause the same problem
      to occur (sig->utime, adds tsk->utime and not task_utime()). This patch
      fixes the problem
      
      TODO: using max(task->prev_utime, derived utime) works for now, but a more
      generic solution is to implement cputime_max() and use the cputime_gt()
      function for comparison.
      
      Reported-by: spencer@bluehost.com
      Signed-off-by: NBalbir Singh <balbir@linux.vnet.ibm.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      49048622
  10. 28 8月, 2008 3 次提交
  11. 26 8月, 2008 1 次提交
  12. 22 8月, 2008 3 次提交
  13. 19 8月, 2008 3 次提交
  14. 16 8月, 2008 1 次提交
  15. 15 8月, 2008 1 次提交
  16. 14 8月, 2008 1 次提交
    • Z
      sched: fix the race between walk_tg_tree and sched_create_group · 09f2724a
      Zhang, Yanmin 提交于
      With 2.6.27-rc3, I hit a kernel panic when running volanoMark on my
      new x86_64 machine. I also hit it with other 2.6.27-rc kernels.
      See below log.
      
      Basically, function walk_tg_tree and sched_create_group have a race
      between accessing and initiating tg->children. Below patch fixes it
      by moving tg->children initiation to the front of linking tg->siblings
      to parent->children.
      
      {----------------panic log------------}
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
      IP: [<ffffffff802292ab>] walk_tg_tree+0x45/0x7f
      PGD 1be1c4067 PUD 1bdd8d067 PMD 0
      Oops: 0000 [1] SMP
      CPU 11
      Modules linked in: igb
      Pid: 22979, comm: java Not tainted 2.6.27-rc3 #1
      RIP: 0010:[<ffffffff802292ab>]  [<ffffffff802292ab>] walk_tg_tree+0x45/0x7f
      RSP: 0018:ffff8801bfbbbd18  EFLAGS: 00010083
      RAX: 0000000000000000 RBX: ffff8800be0dce40 RCX: ffffffffffffffc0
      RDX: ffff880102c43740 RSI: 0000000000000000 RDI: ffff8800be0dce40
      RBP: ffff8801bfbbbd48 R08: ffff8800ba437bc8 R09: 0000000000001f40
      R10: ffff8801be812100 R11: ffffffff805fdf44 R12: ffff880102c43740
      R13: 0000000000000000 R14: ffffffff8022cf0f R15: ffffffff8022749f
      FS:  00000000568ac950(0063) GS:ffff8801bfa26d00(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000000 CR3: 00000001bd848000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process java (pid: 22979, threadinfo ffff8801b145a000, task ffff8801bf18e450)
      Stack:  0000000000000001 ffff8800ba5c8d60 0000000000000001 0000000000000001
       ffff8800bad1ccb8 0000000000000000 ffff8801bfbbbd98 ffffffff8022ed37
       0000000000000001 0000000000000286 ffff8801bd5ee180 ffff8800ba437bc8
      Call Trace:
       <IRQ>  [<ffffffff8022ed37>] try_to_wake_up+0x71/0x24c
       [<ffffffff80247177>] autoremove_wake_function+0x9/0x2e
       [<ffffffff80228039>] ? __wake_up_common+0x46/0x76
       [<ffffffff802296d5>] __wake_up+0x38/0x4f
       [<ffffffff806169cc>] tcp_v4_rcv+0x380/0x62e
      Signed-off-by: NZhang Yanmin <yanmin_zhang@linux.intel.com>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      09f2724a
  17. 11 8月, 2008 1 次提交
    • P
      lockdep: re-annotate scheduler runqueues · 1b12bbc7
      Peter Zijlstra 提交于
      Instead of using a per-rq lock class, use the regular nesting operations.
      
      However, take extra care with double_lock_balance() as it can release the
      already held rq->lock (and therefore change its nesting class).
      
      So what can happen is:
      
       spin_lock(rq->lock);	// this rq subclass 0
      
       double_lock_balance(rq, other_rq);
         // release rq
         // acquire other_rq->lock subclass 0
         // acquire rq->lock subclass 1
      
       spin_unlock(other_rq->lock);
      
      leaving you with rq->lock in subclass 1
      
      So a subsequent double_lock_balance() call can try to nest a subclass 1
      lock while already holding a subclass 1 lock.
      
      Fix this by introducing double_unlock_balance() which releases the other
      rq's lock, but also re-sets the subclass for this rq's lock to 0.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1b12bbc7
  18. 05 8月, 2008 1 次提交
  19. 01 8月, 2008 1 次提交
    • P
      lockdep: change scheduler annotation · 5e710e37
      Peter Zijlstra 提交于
      While thinking about David's graph walk lockdep patch it _finally_
      dawned on me that there is no reason we have a lock class per cpu ...
      
      Sorry for being dense :-/
      
      The below changes the annotation from a lock class per cpu, to a single
      nested lock, as the scheduler never holds more that 2 rq locks at a time
      anyway.
      
      If there was code requiring holding all rq locks this would not work and
      the original annotation would be the only option, but that not being the
      case, this is a much lighter one.
      
      Compiles and boots on a 2-way x86_64.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5e710e37
  20. 31 7月, 2008 1 次提交
  21. 28 7月, 2008 1 次提交
  22. 27 7月, 2008 2 次提交
  23. 26 7月, 2008 1 次提交
  24. 22 7月, 2008 1 次提交
    • A
      sysdev: Pass the attribute to the low level sysdev show/store function · 4a0b2b4d
      Andi Kleen 提交于
      This allow to dynamically generate attributes and share show/store
      functions between attributes. Right now most attributes are generated
      by special macros and lots of duplicated code. With the attribute
      passed it's instead possible to attach some data to the attribute
      and then use that in shared low level functions to do different things.
      
      I need this for the dynamically generated bank attributes in the x86
      machine check code, but it'll allow some further cleanups.
      
      I converted all users in tree to the new show/store prototype. It's a single
      huge patch to avoid unbisectable sections.
      
      Runtime tested: x86-32, x86-64
      Compiled only: ia64, powerpc
      Not compile tested/only grep converted: sh, arm, avr32
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4a0b2b4d
  25. 20 7月, 2008 2 次提交
    • I
      sched: hrtick_enabled() should use cpu_active() · ba42059f
      Ingo Molnar 提交于
      Peter pointed out that hrtick_enabled() should use cpu_active().
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ba42059f
    • P
      sched, x86: clean up hrtick implementation · 31656519
      Peter Zijlstra 提交于
      random uvesafb failures were reported against Gentoo:
      
        http://bugs.gentoo.org/show_bug.cgi?id=222799
      
      and Mihai Moldovan bisected it back to:
      
      > 8f4d37ec is first bad commit
      > commit 8f4d37ec
      > Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
      > Date:   Fri Jan 25 21:08:29 2008 +0100
      >
      >    sched: high-res preemption tick
      
      Linus suspected it to be hrtick + vm86 interaction and observed:
      
      > Btw, Peter, Ingo: I think that commit is doing bad things. They aren't
      > _incorrect_ per se, but they are definitely bad.
      >
      > Why?
      >
      > Using random _TIF_WORK_MASK flags is really impolite for doing
      > "scheduling" work. There's a reason that arch/x86/kernel/entry_32.S
      > special-cases the _TIF_NEED_RESCHED flag: we don't want to exit out of
      > vm86 mode unnecessarily.
      >
      > See the "work_notifysig_v86" label, and how it does that
      > "save_v86_state()" thing etc etc.
      
      Right, I never liked having to fiddle with those TIF flags. Initially I
      needed it because the hrtimer base lock could not nest in the rq lock.
      That however is fixed these days.
      
      Currently the only reason left to fiddle with the TIF flags is remote
      wakeups. We cannot program a remote cpu's hrtimer. I've been thinking
      about using the new and improved IPI function call stuff to implement
      hrtimer_start_on().
      
      However that does require that smp_call_function_single(.wait=0) works
      from interrupt context - /me looks at the latest series from Jens - Yes
      that does seem to be supported, good.
      
      Here's a stab at cleaning this stuff up ...
      
      Mihai reported test success as well.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Tested-by: NMihai Moldovan <ionic@ionic.de>
      Cc: Michal Januszewski <spock@gentoo.org>
      Cc: Antonino Daplas <adaplas@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      31656519
  26. 18 7月, 2008 2 次提交
    • M
      cpu hotplug, sched: Introduce cpu_active_map and redo sched domain managment (take 2) · e761b772
      Max Krasnyansky 提交于
      This is based on Linus' idea of creating cpu_active_map that prevents
      scheduler load balancer from migrating tasks to the cpu that is going
      down.
      
      It allows us to simplify domain management code and avoid unecessary
      domain rebuilds during cpu hotplug event handling.
      
      Please ignore the cpusets part for now. It needs some more work in order
      to avoid crazy lock nesting. Although I did simplfy and unify domain
      reinitialization logic. We now simply call partition_sched_domains() in
      all the cases. This means that we're using exact same code paths as in
      cpusets case and hence the test below cover cpusets too.
      Cpuset changes to make rebuild_sched_domains() callable from various
      contexts are in the separate patch (right next after this one).
      
      This not only boots but also easily handles
      	while true; do make clean; make -j 8; done
      and
      	while true; do on-off-cpu 1; done
      at the same time.
      (on-off-cpu 1 simple does echo 0/1 > /sys/.../cpu1/online thing).
      
      Suprisingly the box (dual-core Core2) is quite usable. In fact I'm typing
      this on right now in gnome-terminal and things are moving just fine.
      
      Also this is running with most of the debug features enabled (lockdep,
      mutex, etc) no BUG_ONs or lockdep complaints so far.
      
      I believe I addressed all of the Dmitry's comments for original Linus'
      version. I changed both fair and rt balancer to mask out non-active cpus.
      And replaced cpu_is_offline() with !cpu_active() in the main scheduler
      code where it made sense (to me).
      Signed-off-by: NMax Krasnyanskiy <maxk@qualcomm.com>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NGregory Haskins <ghaskins@novell.com>
      Cc: dmitry.adamushko@gmail.com
      Cc: pj@sgi.com
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e761b772
    • M
      sched: reduce stack size in isolated_cpu_setup() · 13b40c1e
      Mike Travis 提交于
        * Remove 16k stack requirements in isolated_cpu_setup when NR_CPUS=4096.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      13b40c1e
  27. 11 7月, 2008 1 次提交
  28. 10 7月, 2008 1 次提交
    • D
      sched: fix cpu hotplug · dc7fab8b
      Dmitry Adamushko 提交于
      I think we may have a race between try_to_wake_up() and
      migrate_live_tasks() -> move_task_off_dead_cpu() when the later one
      may end up looping endlessly.
      
      Interrupts are enabled on other CPUs when migration_call(CPU_DEAD, ...) is
      called so we may get a race between try_to_wake_up() and
      migrate_live_tasks() -> move_task_off_dead_cpu(). The former one may push
      a task out of a dead CPU causing the later one to loop endlessly.
      
      Heiko Carstens observed:
      
      | That's exactly what explains a dump I got yesterday. Thanks for fixing! :)
      Signed-off-by: NDmitry Adamushko <dmitry.adamushko@gmail.com>
      Cc: miaox@cn.fujitsu.com
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Avi Kivity <avi@qumranet.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      dc7fab8b