1. 12 5月, 2011 1 次提交
  2. 06 5月, 2011 1 次提交
  3. 16 4月, 2011 1 次提交
  4. 12 4月, 2011 2 次提交
  5. 28 3月, 2011 1 次提交
    • L
      Btrfs: add initial tracepoint support for btrfs · 1abe9b8a
      liubo 提交于
      Tracepoints can provide insight into why btrfs hits bugs and be greatly
      helpful for debugging, e.g
                    dd-7822  [000]  2121.641088: btrfs_inode_request: root = 5(FS_TREE), gen = 4, ino = 256, blocks = 8, disk_i_size = 0, last_trans = 8, logged_trans = 0
                    dd-7822  [000]  2121.641100: btrfs_inode_new: root = 5(FS_TREE), gen = 8, ino = 257, blocks = 0, disk_i_size = 0, last_trans = 0, logged_trans = 0
       btrfs-transacti-7804  [001]  2146.935420: btrfs_cow_block: root = 2(EXTENT_TREE), refs = 2, orig_buf = 29368320 (orig_level = 0), cow_buf = 29388800 (cow_level = 0)
       btrfs-transacti-7804  [001]  2146.935473: btrfs_cow_block: root = 1(ROOT_TREE), refs = 2, orig_buf = 29364224 (orig_level = 0), cow_buf = 29392896 (cow_level = 0)
       btrfs-transacti-7804  [001]  2146.972221: btrfs_transaction_commit: root = 1(ROOT_TREE), gen = 8
         flush-btrfs-2-7821  [001]  2155.824210: btrfs_chunk_alloc: root = 3(CHUNK_TREE), offset = 1103101952, size = 1073741824, num_stripes = 1, sub_stripes = 0, type = DATA
         flush-btrfs-2-7821  [001]  2155.824241: btrfs_cow_block: root = 2(EXTENT_TREE), refs = 2, orig_buf = 29388800 (orig_level = 0), cow_buf = 29396992 (cow_level = 0)
         flush-btrfs-2-7821  [001]  2155.824255: btrfs_cow_block: root = 4(DEV_TREE), refs = 2, orig_buf = 29372416 (orig_level = 0), cow_buf = 29401088 (cow_level = 0)
         flush-btrfs-2-7821  [000]  2155.824329: btrfs_cow_block: root = 3(CHUNK_TREE), refs = 2, orig_buf = 20971520 (orig_level = 0), cow_buf = 20975616 (cow_level = 0)
       btrfs-endio-wri-7800  [001]  2155.898019: btrfs_cow_block: root = 5(FS_TREE), refs = 2, orig_buf = 29384704 (orig_level = 0), cow_buf = 29405184 (cow_level = 0)
       btrfs-endio-wri-7800  [001]  2155.898043: btrfs_cow_block: root = 7(CSUM_TREE), refs = 2, orig_buf = 29376512 (orig_level = 0), cow_buf = 29409280 (cow_level = 0)
      
      Here is what I have added:
      
      1) ordere_extent:
              btrfs_ordered_extent_add
              btrfs_ordered_extent_remove
              btrfs_ordered_extent_start
              btrfs_ordered_extent_put
      
      These provide critical information to understand how ordered_extents are
      updated.
      
      2) extent_map:
              btrfs_get_extent
      
      extent_map is used in both read and write cases, and it is useful for tracking
      how btrfs specific IO is running.
      
      3) writepage:
              __extent_writepage
              btrfs_writepage_end_io_hook
      
      Pages are cirtical resourses and produce a lot of corner cases during writeback,
      so it is valuable to know how page is written to disk.
      
      4) inode:
              btrfs_inode_new
              btrfs_inode_request
              btrfs_inode_evict
      
      These can show where and when a inode is created, when a inode is evicted.
      
      5) sync:
              btrfs_sync_file
              btrfs_sync_fs
      
      These show sync arguments.
      
      6) transaction:
              btrfs_transaction_commit
      
      In transaction based filesystem, it will be useful to know the generation and
      who does commit.
      
      7) back reference and cow:
      	btrfs_delayed_tree_ref
      	btrfs_delayed_data_ref
      	btrfs_delayed_ref_head
      	btrfs_cow_block
      
      Btrfs natively supports back references, these tracepoints are helpful on
      understanding btrfs's COW mechanism.
      
      8) chunk:
      	btrfs_chunk_alloc
      	btrfs_chunk_free
      
      Chunk is a link between physical offset and logical offset, and stands for space
      infomation in btrfs, and these are helpful on tracing space things.
      
      9) reserved_extent:
      	btrfs_reserved_extent_alloc
      	btrfs_reserved_extent_free
      
      These can show how btrfs uses its space.
      Signed-off-by: NLiu Bo <liubo2009@cn.fujitsu.com>
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      1abe9b8a
  6. 22 3月, 2011 1 次提交
  7. 15 3月, 2011 1 次提交
  8. 10 3月, 2011 3 次提交
  9. 03 3月, 2011 1 次提交
    • T
      blktrace: Remove blk_fill_rwbs_rq. · 2d3a8497
      Tao Ma 提交于
      If we enable trace events to trace block actions, We use
      blk_fill_rwbs_rq to analyze the corresponding actions
      in request's cmd_flags, but we only choose the minor 2 bits
      from it, so most of other flags(e.g, REQ_SYNC) are missing.
      For example, with a sync write we get:
      write_test-2409  [001]   160.013869: block_rq_insert: 3,64 W 0 () 258135 + =
      8 [write_test]
      
      Since now we have integrated the flags of both bio and request,
      it is safe to pass rq->cmd_flags directly to blk_fill_rwbs and
      blk_fill_rwbs_rq isn't needed any more.
      
      With this patch, after a sync write we get:
      write_test-2417  [000]   226.603878: block_rq_insert: 3,64 WS 0 () 258135 +=
       8 [write_test]
      Signed-off-by: NTao Ma <boyu.mt@taobao.com>
      Acked-by: NJeff Moyer <jmoyer@redhat.com>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      2d3a8497
  10. 02 3月, 2011 1 次提交
  11. 03 2月, 2011 1 次提交
    • S
      tracing: Replace trace_event struct array with pointer array · e4a9ea5e
      Steven Rostedt 提交于
      Currently the trace_event structures are placed in the _ftrace_events
      section, and at link time, the linker makes one large array of all
      the trace_event structures. On boot up, this array is read (much like
      the initcall sections) and the events are processed.
      
      The problem is that there is no guarantee that gcc will place complex
      structures nicely together in an array format. Two structures in the
      same file may be placed awkwardly, because gcc has no clue that they
      are suppose to be in an array.
      
      A hack was used previous to force the alignment to 4, to pack the
      structures together. But this caused alignment issues with other
      architectures (sparc).
      
      Instead of packing the structures into an array, the structures' addresses
      are now put into the _ftrace_event section. As pointers are always the
      natural alignment, gcc should always pack them tightly together
      (otherwise initcall, extable, etc would also fail).
      
      By having the pointers to the structures in the section, we can still
      iterate the trace_events without causing unnecessary alignment problems
      with other architectures, or depending on the current behaviour of
      gcc that will likely change in the future just to tick us kernel developers
      off a little more.
      
      The _ftrace_event section is also moved into the .init.data section
      as it is now only needed at boot up.
      Suggested-by: NDavid Miller <davem@davemloft.net>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      e4a9ea5e
  12. 22 1月, 2011 1 次提交
  13. 15 1月, 2011 1 次提交
    • S
      tracing: Only process module tracepoints once · c94fbe1d
      Steven Rostedt 提交于
      The commit:
      
       9f987b3141f086de27832514aad9f50a53f754
       tracing: Include module.h in define_trace.h
      
      only solved half the problem. If the trace/events/module.h header is
      included at the time of define_trace.h (or in ftrace.h within it),
      the module.h TRACE_SYSTEM will override the current TRACE_SYSTEM
      macro.
      
      Since define_trace.h is included when CREATE_TRACE_POINTS is set,
      and the first thing it does is to #undef CREATE_TRACE_POINTS,
      by placing the module.h TRACE_SYSTEM inside a
       #ifdef CREATE_TRACE_POINTS
      we can prevent it from overriding the TRACE_SYSTEM that is
      being processed, and still process the module.h tracepoints
      when the module code defines CREATE_TRACE_POINTS and includes
      the trace/events/module.h header.
      
      As with commit 9f987b3141, this is only an issue if module.h
      is not included before the trace/events/<event>.h file is
      included, which (luckily) has not happened yet.
      Reported-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      c94fbe1d
  14. 14 1月, 2011 4 次提交
  15. 12 1月, 2011 6 次提交
  16. 08 1月, 2011 2 次提交
  17. 07 1月, 2011 1 次提交
  18. 04 1月, 2011 1 次提交
    • T
      perf: Clean up power events by introducing new, more generic ones · 25e41933
      Thomas Renninger 提交于
      Add these new power trace events:
      
       power:cpu_idle
       power:cpu_frequency
       power:machine_suspend
      
      The old C-state/idle accounting events:
        power:power_start
        power:power_end
      
      Have now a replacement (but we are still keeping the old
      tracepoints for compatibility):
      
        power:cpu_idle
      
      and
        power:power_frequency
      
      is replaced with:
        power:cpu_frequency
      
      power:machine_suspend is newly introduced.
      
      Jean Pihet has a patch integrated into the generic layer
      (kernel/power/suspend.c) which will make use of it.
      
      the type= field got removed from both, it was never
      used and the type is differed by the event type itself.
      
      perf timechart userspace tool gets adjusted in a separate patch.
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NArjan van de Ven <arjan@linux.intel.com>
      Acked-by: NJean Pihet <jean.pihet@newoldbits.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: rjw@sisk.pl
      LKML-Reference: <1294073445-14812-3-git-send-email-trenn@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      LKML-Reference: <1290072314-31155-2-git-send-email-trenn@suse.de>
      25e41933
  19. 06 12月, 2010 1 次提交
  20. 03 12月, 2010 1 次提交
    • S
      tracing: Add TRACE_EVENT_CONDITIONAL() · 287050d3
      Steven Rostedt 提交于
      There are instances in the kernel that we only want to trace
      a tracepoint when a certain condition is set. But we do not
      want to test for that condition in the core kernel.
      If we test for that condition before calling the tracepoin, then
      we will be performing that test even when tracing is not enabled.
      This is 99.99% of the time.
      
      We currently can just filter out on that condition, but that happens
      after we write to the trace buffer. We just wasted time writing to
      the ring buffer for an event we never cared about.
      
      This patch adds:
      
         TRACE_EVENT_CONDITION() and DEFINE_EVENT_CONDITION()
      
      These have a new TP_CONDITION() argument that comes right after
      the TP_ARGS().  This condition can use the parameters of TP_ARGS()
      in the TRACE_EVENT() to determine if the tracepoint should be traced
      or not. The TP_CONDITION() will be placed in a if (cond) trace;
      
      For example, for the tracepoint sched_wakeup, it is useless to
      trace a wakeup event where the caller never actually wakes
      anything up (where success == 0). So adding:
      
      	TP_CONDITION(success),
      
      which uses the "success" parameter of the wakeup tracepoint
      will have it only trace when we have successfully woken up a
      task.
      Acked-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Acked-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      287050d3
  21. 19 11月, 2010 1 次提交
    • S
      tracing/events: Show real number in array fields · 04295780
      Steven Rostedt 提交于
      Currently we have in something like the sched_switch event:
      
        field:char prev_comm[TASK_COMM_LEN];	offset:12;	size:16;	signed:1;
      
      When a userspace tool such as perf tries to parse this, the
      TASK_COMM_LEN is meaningless. This is done because the TRACE_EVENT() macro
      simply uses a #len to show the string of the length. When the length is
      an enum, we get a string that means nothing for tools.
      
      By adding a static buffer and a mutex to protect it, we can store the
      string into that buffer with snprintf and show the actual number.
      Now we get:
      
        field:char prev_comm[16];       offset:12;      size:16;        signed:1;
      
      Something much more useful.
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      04295780
  22. 18 11月, 2010 3 次提交
    • F
      tracing: Allow syscall trace events for non privileged users · 53cf810b
      Frederic Weisbecker 提交于
      As for the raw syscalls events, individual syscall events won't
      leak system wide information on task bound tracing. Allow non
      privileged users to use them in such workflow.
      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: Thomas Gleixner <tglx@linutronix.de>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Cc: Jason Baron <jbaron@redhat.com>
      53cf810b
    • F
      tracing: Allow raw syscall trace events for non privileged users · fe554203
      Frederic Weisbecker 提交于
      This allows non privileged users to use the raw syscall trace events
      for task bound tracing in perf.
      
      It is safe because raw syscall trace events don't leak system wide
      informations.
      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: Thomas Gleixner <tglx@linutronix.de>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Cc: Jason Baron <jbaron@redhat.com>
      fe554203
    • F
      tracing: New macro to set up initial event flags value · 1ed0c597
      Frederic Weisbecker 提交于
      This introduces the new TRACE_EVENT_FLAGS() macro in order
      to set up initial event flags value.
      
      This macro must simply follow the definition of a trace event
      and take the event name and the flag value as parameters:
      
      TRACE_EVENT(my_event, .....
      ....
      );
      
      TRACE_EVENT_FLAGS(my_event, 1)
      
      This will set up 1 as the initial my_event->flags value.
      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: Thomas Gleixner <tglx@linutronix.de>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Cc: Jason Baron <jbaron@redhat.com>
      1ed0c597
  23. 16 11月, 2010 1 次提交
  24. 11 11月, 2010 2 次提交
    • M
      ASoC: Add DAPM trace events · 84e90930
      Mark Brown 提交于
      Trace events for DAPM allow us to monitor the performance and behaviour
      of DAPM with logging which can be built into the kernel permanantly, is
      more suited to automated analysis and display and less likely to suffer
      interference from other logging activity.
      
      Currently trace events are generated for:
      
      - Start and stop of DAPM processing
      - Start and stop of bias level changes
      - Power decisions for widgets
      - Widget event execution start and stop
      
      giving some view as to what is happening and where latencies occur.
      
      Actual changes in widget power can be seen via the register write trace in
      soc-core.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
      84e90930
    • M
      ASoC: Add trace events for ASoC register read/write · a8b1d34f
      Mark Brown 提交于
      The trace subsystem provides a convenient way of instrumenting the kernel
      which can be left on all the time with extremely low impact on the system
      unlike prints to the kernel log which can be very spammy. Begin adding
      support for instrumenting ASoC via this interface by adding trace for the
      register access primitives.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
      a8b1d34f
  25. 09 11月, 2010 1 次提交