1. 02 8月, 2010 5 次提交
    • F
      perf, sched migration: Ignore unhandled task states · 207f90fc
      Frederic Weisbecker 提交于
      Stop printing an error message when we don't have the letter
      for a given task state. All we need to know is if the task is
      in the TASK_RUNNING state.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Nikhil Rao <ncrao@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      207f90fc
    • F
      perf, sched migration: Handle ignored migrate out events · 749e5074
      Frederic Weisbecker 提交于
      Migrate out events may happen on tasks that are not in the
      runqueue, for example this is the case for tasks that are
      sleeping. In this case, we don't want to log the migrate out
      event in the source runqueue because the task is not eventually
      in the runqueue and we have already logged its sleep event.
      
      This fixes timeslices that spuriously propagate a sleep event
      from the previous timeslice.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Nikhil Rao <ncrao@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      749e5074
    • F
      perf: New migration tool overview · 880d22f2
      Frederic Weisbecker 提交于
      This brings a GUI tool that displays an overview of the load
      of tasks proportion in each CPUs.
      
      The CPUs forward progress is cut in timeslices. A new timeslice
      is created for every runqueue event: a task gets pushed out or
      pulled in the runqueue.
      
      For each timeslice, every CPUs rectangle is colored with a red
      power that describes the local load against the total load.
      This more red is the rectangle, the higher is the given CPU load.
      This load is the number of tasks running on the CPU, without
      any distinction against the scheduler policy of the tasks, for
      now.
      
      Also for each timeslice, the event origin is depicted on the
      CPUs that triggered it using a thin colored line on top of the
      rectangle timeslice.
      
      These events are:
      
      * sleep: a task went to sleep and has then been pulled out the
        runqueue. The origin color in the thin line is dark blue.
      
      * wake up: a task woke up and has then been pushed in the
        runqueue. The origin color is yellow.
      
      * wake up new: a new task woke up and has then been pushed in the
        runqueue. The origin color is green.
      
      * migrate in: a task migrated in the runqueue due to a load
        balancing operation. The origin color is violet.
      
      * migrate out: reverse of the previous one. Migrate in events
        usually have paired migrate out events in another runqueue.
        The origin color is light blue.
      
      Clicking on a timeslice provides the runqueue event details
      and the runqueue state.
      
      The CPU rectangles can be navigated using the usual arrow
      controls. Horizontal zooming in/out is possible with the
      "+" and "-" buttons.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Venkatesh Pallipadi <venki@google.com>
      Cc: Pierre Tardy <tardyp@gmail.com>
      Cc: Nikhil Rao <ncrao@google.com>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      880d22f2
    • F
      tracing: Drop cpparg() macro · 819ce45a
      Frederic Weisbecker 提交于
      Drop the cpparg() macro that wraps CPP parameters. We already have
      the PARAM() macro for that, no need to have several versions.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      819ce45a
    • F
      perf: Use tracepoint_synchronize_unregister() to flush any pending tracepoint call · 669336e4
      Frederic Weisbecker 提交于
      We use synchronize_sched() to ensure a tracepoint won't be called
      while/after we release the perf buffers it references.
      
      But the tracepoint API has its own API for that:
      tracepoint_synchronize_unregister(). Use it instead as it's
      self-explanatory and eases maintainance.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      669336e4
  2. 23 7月, 2010 3 次提交
  3. 22 7月, 2010 8 次提交
  4. 21 7月, 2010 24 次提交