1. 26 1月, 2008 1 次提交
    • P
      sched: high-res preemption tick · 8f4d37ec
      Peter Zijlstra 提交于
      Use HR-timers (when available) to deliver an accurate preemption tick.
      
      The regular scheduler tick that runs at 1/HZ can be too coarse when nice
      level are used. The fairness system will still keep the cpu utilisation 'fair'
      by then delaying the task that got an excessive amount of CPU time but try to
      minimize this by delivering preemption points spot-on.
      
      The average frequency of this extra interrupt is sched_latency / nr_latency.
      Which need not be higher than 1/HZ, its just that the distribution within the
      sched_latency period is important.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8f4d37ec
  2. 19 10月, 2007 1 次提交
  3. 17 7月, 2007 1 次提交
  4. 08 4月, 2007 1 次提交
    • I
      [PATCH] high-res timers: resume fix · 995f054f
      Ingo Molnar 提交于
      Soeren Sonnenburg reported that upon resume he is getting
      this backtrace:
      
       [<c0119637>] smp_apic_timer_interrupt+0x57/0x90
       [<c0142d30>] retrigger_next_event+0x0/0xb0
       [<c0104d30>] apic_timer_interrupt+0x28/0x30
       [<c0142d30>] retrigger_next_event+0x0/0xb0
       [<c0140068>] __kfifo_put+0x8/0x90
       [<c0130fe5>] on_each_cpu+0x35/0x60
       [<c0143538>] clock_was_set+0x18/0x20
       [<c0135cdc>] timekeeping_resume+0x7c/0xa0
       [<c02aabe1>] __sysdev_resume+0x11/0x80
       [<c02ab0c7>] sysdev_resume+0x47/0x80
       [<c02b0b05>] device_power_up+0x5/0x10
      
      it turns out that on resume we mistakenly re-enable interrupts too
      early.  Do the timer retrigger only on the current CPU.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NSoeren Sonnenburg <kernel@nn7.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      995f054f
  5. 07 3月, 2007 2 次提交
  6. 02 3月, 2007 1 次提交
  7. 17 2月, 2007 10 次提交
  8. 30 9月, 2006 1 次提交
  9. 07 9月, 2006 1 次提交
  10. 04 7月, 2006 1 次提交
  11. 26 6月, 2006 1 次提交
  12. 22 4月, 2006 1 次提交
  13. 02 4月, 2006 1 次提交
  14. 01 4月, 2006 1 次提交
  15. 27 3月, 2006 5 次提交
  16. 07 3月, 2006 1 次提交
    • T
      [PATCH] fix next_timer_interrupt() for hrtimer · 69239749
      Tony Lindgren 提交于
      Also from Thomas Gleixner <tglx@linutronix.de>
      
      Function next_timer_interrupt() got broken with a recent patch
      6ba1b912 as sys_nanosleep() was moved to
      hrtimer.  This broke things as next_timer_interrupt() did not check hrtimer
      tree for next event.
      
      Function next_timer_interrupt() is needed with dyntick (CONFIG_NO_IDLE_HZ,
      VST) implementations, as the system can be in idle when next hrtimer event
      was supposed to happen.  At least ARM and S390 currently use
      next_timer_interrupt().
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      69239749
  17. 02 2月, 2006 2 次提交
  18. 12 1月, 2006 3 次提交
  19. 11 1月, 2006 3 次提交