1. 20 8月, 2009 1 次提交
  2. 26 6月, 2009 1 次提交
  3. 09 6月, 2009 1 次提交
  4. 03 4月, 2009 1 次提交
  5. 23 2月, 2009 4 次提交
  6. 31 12月, 2008 1 次提交
    • M
      [PATCH] idle cputime accounting · 79741dd3
      Martin Schwidefsky 提交于
      The cpu time spent by the idle process actually doing something is
      currently accounted as idle time. This is plain wrong, the architectures
      that support VIRT_CPU_ACCOUNTING=y can do better: distinguish between the
      time spent doing nothing and the time spent by idle doing work. The first
      is accounted with account_idle_time and the second with account_system_time.
      The architectures that use the account_xxx_time interface directly and not
      the account_xxx_ticks interface now need to do the check for the idle
      process in their arch code. In particular to improve the system vs true
      idle time accounting the arch code needs to measure the true idle time
      instead of just testing for the idle process.
      To improve the tick based accounting as well we would need an architecture
      primitive that can tell us if the pt_regs of the interrupted context
      points to the magic instruction that halts the cpu.
      
      In addition idle time is no more added to the stime of the idle process.
      This field now contains the system time of the idle process as it should
      be. On systems without VIRT_CPU_ACCOUNTING this will always be zero as
      every tick that occurs while idle is running will be accounted as idle
      time.
      
      This patch contains the necessary common code changes to be able to
      distinguish idle system time and true idle time. The architectures with
      support for VIRT_CPU_ACCOUNTING need some changes to exploit this.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      79741dd3
  7. 03 12月, 2008 2 次提交
  8. 04 8月, 2008 1 次提交
  9. 28 7月, 2008 1 次提交
  10. 26 7月, 2008 1 次提交
  11. 25 7月, 2008 1 次提交
  12. 15 7月, 2008 1 次提交
  13. 09 7月, 2008 1 次提交
  14. 03 7月, 2008 1 次提交
  15. 01 7月, 2008 3 次提交
  16. 29 4月, 2008 1 次提交
    • K
      [POWERPC] Add IRQSTACKS support on ppc32 · 85218827
      Kumar Gala 提交于
      This makes it possible to use separate stacks for hard and soft IRQs
      on 32-bit powerpc as well as on 64-bit.  The code for 32-bit is just
      the 32-bit analog of the 64-bit code.
      
      * Added allocation and initialization of the irq stacks.  We limit the
        stacks to be in lowmem for ppc32.
      * Implemented ppc32 versions of call_do_softirq() and call_handle_irq()
        to switch the stack pointers
      * Reworked how we do stack overflow detection.  We now keep around the
        limit of the stack in the thread_struct and compare against the limit
        to see if we've overflowed.  We can now use this on ppc64 if desired.
      
      [ paulus@samba.org: Fixed bug on 6xx where we need to reload r9 with the
        thread_info pointer. ]
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      85218827
  17. 24 4月, 2008 1 次提交
  18. 18 4月, 2008 1 次提交
  19. 28 3月, 2008 1 次提交
    • M
      [POWERPC] Fix missed hardware breakpoints across multiple threads · a2ceff5e
      Michael Ellerman 提交于
      There is a bug in the powerpc DABR (data access breakpoint) handling,
      which can result in us missing breakpoints if several threads are trying
      to break on the same address.
      
      The circumstances are that do_page_fault() calls do_dabr(), this clears
      the DABR (sets it to 0) and sets up the signal which will report to
      userspace that the DABR was hit. The do_signal() code will restore the DABR
      value on the way out to userspace.
      
      If we reschedule before calling do_signal(), __switch_to() will check the
      cached DABR value and compare it to the new thread's value, if they match
      we don't set the DABR in hardware.
      
      So if two threads have the same DABR value, and we schedule from one to
      the other after taking the interrupt for the first thread hitting the DABR,
      the second thread will run without the DABR set in hardware.
      
      The cleanest fix is to move the cache update into set_dabr(), that way we
      can't forget to do it.
      Reported-by: NJan Kratochvil <jan.kratochvil@redhat.com>
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      a2ceff5e
  20. 26 3月, 2008 1 次提交
  21. 20 3月, 2008 1 次提交
  22. 14 2月, 2008 1 次提交
  23. 06 12月, 2007 1 次提交
    • T
      [POWERPC] Fix hardware IRQ time accounting problem. · 81a3843f
      Tony Breeds 提交于
      The commit fa13a5a1 (sched: restore
      deterministic CPU accounting on powerpc), unconditionally calls
      update_process_tick() in system context.  In the deterministic
      accounting case this is the correct thing to do.  However, in the
      non-deterministic accounting case we need to not do this, since doing
      this results in the time accounted as hardware irq time being
      artificially elevated.
      
      Also this collapses 2 consecutive '#ifdef CONFIG_VIRT_CPU_ACCOUNTING'
      checks in time.h into one for neatness.
      Signed-off-by: NTony Breeds <tony@bakeyournoodle.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      81a3843f
  24. 10 11月, 2007 1 次提交
    • P
      sched: restore deterministic CPU accounting on powerpc · fa13a5a1
      Paul Mackerras 提交于
      Since powerpc started using CONFIG_GENERIC_CLOCKEVENTS, the
      deterministic CPU accounting (CONFIG_VIRT_CPU_ACCOUNTING) has been
      broken on powerpc, because we end up counting user time twice: once in
      timer_interrupt() and once in update_process_times().
      
      This fixes the problem by pulling the code in update_process_times
      that updates utime and stime into a separate function called
      account_process_tick.  If CONFIG_VIRT_CPU_ACCOUNTING is not defined,
      there is a version of account_process_tick in kernel/timer.c that
      simply accounts a whole tick to either utime or stime as before.  If
      CONFIG_VIRT_CPU_ACCOUNTING is defined, then arch code gets to
      implement account_process_tick.
      
      This also lets us simplify the s390 code a bit; it means that the s390
      timer interrupt can now call update_process_times even when
      CONFIG_VIRT_CPU_ACCOUNTING is turned on, and can just implement a
      suitable account_process_tick().
      
      account_process_tick() now takes the task_struct * as an argument.
      Tested both with and without CONFIG_VIRT_CPU_ACCOUNTING.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fa13a5a1
  25. 20 10月, 2007 1 次提交
  26. 17 10月, 2007 1 次提交
  27. 12 10月, 2007 1 次提交
    • P
      [POWERPC] Use 1TB segments · 1189be65
      Paul Mackerras 提交于
      This makes the kernel use 1TB segments for all kernel mappings and for
      user addresses of 1TB and above, on machines which support them
      (currently POWER5+, POWER6 and PA6T).
      
      We detect that the machine supports 1TB segments by looking at the
      ibm,processor-segment-sizes property in the device tree.
      
      We don't currently use 1TB segments for user addresses < 1T, since
      that would effectively prevent 32-bit processes from using huge pages
      unless we also had a way to revert to using 256MB segments.  That
      would be possible but would involve extra complications (such as
      keeping track of which segment size was used when HPTEs were inserted)
      and is not addressed here.
      
      Parts of this patch were originally written by Ben Herrenschmidt.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      1189be65
  28. 03 10月, 2007 1 次提交
  29. 25 9月, 2007 1 次提交
  30. 14 9月, 2007 1 次提交
  31. 29 8月, 2007 1 次提交
    • K
      [POWERPC] Flush registers to proper task context · 0ee6c15e
      Kumar Gala 提交于
      When we flush register state for FP, Altivec, or SPE in flush_*_to_thread
      we need to respect the task_struct that the caller has passed to us.
      
      Most cases we are called with current, however sometimes (ptrace) we may
      be passed a different task_struct.
      
      This showed up when using gdbserver debugging a simple program that used
      floating point. When gdb tried to show the FP regs they all showed up as
      0, because the child's FP registers were never properly flushed to memory.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      0ee6c15e
  32. 26 7月, 2007 1 次提交
  33. 14 6月, 2007 1 次提交
  34. 09 5月, 2007 1 次提交