1. 18 12月, 2008 1 次提交
  2. 17 11月, 2008 1 次提交
  3. 23 10月, 2008 1 次提交
  4. 17 10月, 2008 2 次提交
  5. 28 9月, 2008 1 次提交
  6. 23 9月, 2008 1 次提交
    • F
      timers: fix itimer/many thread hang, v2 · bb34d92f
      Frank Mayhar 提交于
      This is the second resubmission of the posix timer rework patch, posted
      a few days ago.
      
      This includes the changes from the previous resubmittion, which addressed
      Oleg Nesterov's comments, removing the RCU stuff from the patch and
      un-inlining the thread_group_cputime() function for SMP.
      
      In addition, per Ingo Molnar it simplifies the UP code, consolidating much
      of it with the SMP version and depending on lower-level SMP/UP handling to
      take care of the differences.
      
      It also cleans up some UP compile errors, moves the scheduler stats-related
      macros into kernel/sched_stats.h, cleans up a merge error in
      kernel/fork.c and has a few other minor fixes and cleanups as suggested
      by Oleg and Ingo. Thanks for the review, guys.
      Signed-off-by: NFrank Mayhar <fmayhar@google.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      bb34d92f
  7. 04 7月, 2008 1 次提交
    • A
      sched: fix accounting in task delay accounting & migration · 46ac22ba
      Ankita Garg 提交于
      On Thu, Jun 19, 2008 at 12:27:14PM +0200, Peter Zijlstra wrote:
      > On Thu, 2008-06-05 at 10:50 +0530, Ankita Garg wrote:
      >
      > > Thanks Peter for the explanation...
      > >
      > > I agree with the above and that is the reason why I did not see weird
      > > values with cpu_time. But, run_delay still would suffer skews as the end
      > > points for delta could be taken on different cpus due to migration (more
      > > so on RT kernel due to the push-pull operations). With the below patch,
      > > I could not reproduce the issue I had seen earlier. After every dequeue,
      > > we take the delta and start wait measurements from zero when moved to a
      > > different rq.
      >
      > OK, so task delay delay accounting is broken because it doesn't take
      > migration into account.
      >
      > What you've done is make it symmetric wrt enqueue, and account it like
      >
      >   cpu0      cpu1
      >
      > enqueue
      >  <wait-d1>
      > dequeue
      >             enqueue
      >              <wait-d2>
      >             run
      >
      > Where you add both d1 and d2 to the run_delay,.. right?
      >
      
      Thanks for reviewing the patch. The above is exactly what I have done.
      
      > This seems like a good fix, however it looks like the patch will break
      > compilation in !CONFIG_SCHEDSTATS && !CONFIG_TASK_DELAY_ACCT, of it
      > failing to provide a stub for sched_info_dequeue() in that case.
      
      Fixed. Pl. find the new patch below.
      Signed-off-by: NAnkita Garg <ankita@in.ibm.com>
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: Gregory Haskins <ghaskins@novell.com>
      Cc: rostedt@goodmis.org
      Cc: suresh.b.siddha@intel.com
      Cc: aneesh.kumar@linux.vnet.ibm.com
      Cc: dhaval@linux.vnet.ibm.com
      Cc: vatsa@linux.vnet.ibm.com
      Cc: David Bahi <DBahi@novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      46ac22ba
  8. 19 6月, 2008 1 次提交
    • B
      sched, delay accounting: fix incorrect delay time when constantly waiting on runqueue · d4abc238
      Bharath Ravi 提交于
      This patch corrects the incorrect value of per process run-queue wait
      time reported by delay statistics. The anomaly was due to the following
      reason. When a process leaves the CPU and immediately starts waiting for
      CPU on the runqueue (which means it remains in the TASK_RUNNABLE state),
      the time of re-entry into the run-queue is never recorded. Due to this,
      the waiting time on the runqueue from this point of re-entry upto the
      next time it hits the CPU is not accounted for. This is solved by
      recording the time of re-entry of a process leaving the CPU in the
      sched_info_depart() function IF the process will go back to waiting on
      the run-queue. This IF condition is verified by checking whether the
      process is still in the TASK_RUNNABLE state.
      
      The patch was tested on 2.6.26-rc6 using two simple CPU hog programs.
      The values noted prior to the fix did not account for the time spent on
      the runqueue waiting. After the fix, the correct values were reported
      back to user space.
      Signed-off-by: NBharath Ravi <bharathravi1@gmail.com>
      Signed-off-by: NMadhava K R  <madhavakr@gmail.com>
      Cc: dhaval@linux.vnet.ibm.com
      Cc: vatsa@in.ibm.com
      Cc: balbir@in.ibm.com
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d4abc238
  9. 29 5月, 2008 1 次提交
  10. 20 4月, 2008 1 次提交
  11. 28 11月, 2007 1 次提交
  12. 10 11月, 2007 1 次提交
  13. 19 10月, 2007 1 次提交
    • K
      sched: reduce schedstat variable overhead a bit · 480b9434
      Ken Chen 提交于
      schedstat is useful in investigating CPU scheduler behavior.  Ideally,
      I think it is beneficial to have it on all the time.  However, the
      cost of turning it on in production system is quite high, largely due
      to number of events it collects and also due to its large memory
      footprint.
      
      Most of the fields probably don't need to be full 64-bit on 64-bit
      arch.  Rolling over 4 billion events will most like take a long time
      and user space tool can be made to accommodate that.  I'm proposing
      kernel to cut back most of variable width on 64-bit system.  (note,
      the following patch doesn't affect 32-bit system).
      Signed-off-by: NKen Chen <kenchen@google.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      480b9434
  14. 15 10月, 2007 2 次提交
  15. 02 8月, 2007 1 次提交
  16. 10 7月, 2007 2 次提交