10 Jul, 2009

1 commit

  • The stat entries can be freed when the stat file is being read.
    The worse is, the ptr can be freed immediately after it's returned
    from workqueue_stat_start/next().

    Add a refcnt to struct cpu_workqueue_stats to avoid use-after-free.

    Signed-off-by: Lai Jiangshan
    Signed-off-by: Li Zefan
    Acked-by: Frederic Weisbecker
    Cc: Steven Rostedt
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Lai Jiangshan
     

02 Jun, 2009

4 commits

  • The blankline between each cpu's workqueue stat is not necessary, because
    the cpu number is enough to part them by eye.
    Old style also caused a blankline below headline, and made code complex
    by using lock, disableirq and get cpu var.

    Old style:
    # CPU INSERTED EXECUTED NAME
    # | | | |

    0 8644 8644 events/0
    0 0 0 cpuset
    ...
    0 1 1 kdmflush

    1 35365 35365 events/1
    ...

    New style:
    # CPU INSERTED EXECUTED NAME
    # | | | |

    0 8644 8644 events/0
    0 0 0 cpuset
    ...
    0 1 1 kdmflush
    1 35365 35365 events/1
    ...

    [ Impact: provide more readable code ]

    Signed-off-by: Zhao Lei
    Cc: KOSAKI Motohiro
    Cc: Steven Rostedt
    Cc: Tom Zanussi
    Cc: Oleg Nesterov
    Cc: Andrew Morton
    Signed-off-by: Frederic Weisbecker

    Zhaolei
     
  • cpu_workqueue_stats->first_entry is useless because we can retrieve the
    header of a cpu workqueue using:
    if (&cpu_workqueue_stats->list == workqueue_cpu_stat(cpu)->list.next)

    [ Impact: cleanup ]

    Signed-off-by: Zhao Lei
    Cc: Steven Rostedt
    Cc: Tom Zanussi
    Cc: Oleg Nesterov
    Cc: Andrew Morton
    Signed-off-by: Frederic Weisbecker

    Zhaolei
     
  • No need to use list_for_each_entry_safe() in iteration without deleting
    any node, we can use list_for_each_entry() instead.

    [ Impact: cleanup ]

    Signed-off-by: Zhao Lei
    Cc: Steven Rostedt
    Cc: Tom Zanussi
    Cc: Oleg Nesterov
    Cc: Andrew Morton
    Signed-off-by: Frederic Weisbecker

    Zhaolei
     
  • v3: zhaolei@cn.fujitsu.com: Change TRACE_EVENT definition to new format
    introduced by Steven Rostedt: consolidate trace and trace_event headers
    v2: kosaki@jp.fujitsu.com: print the function names instead of addr, and zap
    the work addr
    v1: zhaolei@cn.fujitsu.com: Make workqueue tracepoints use TRACE_EVENT macro

    TRACE_EVENT is a more generic way to define tracepoints.
    Doing so adds these new capabilities to the tracepoints:

    - zero-copy and per-cpu splice() tracing
    - binary tracing without printf overhead
    - structured logging records exposed under /debug/tracing/events
    - trace events embedded in function tracer output and other plugins
    - user-defined, per tracepoint filter expressions

    Then, this patch converts DEFINE_TRACE to TRACE_EVENT in workqueue related
    tracepoints.

    [ Impact: expand workqueue tracer to events tracing ]

    Signed-off-by: Zhao Lei
    Cc: Steven Rostedt
    Cc: Tom Zanussi
    Cc: Oleg Nesterov
    Cc: Andrew Morton
    Signed-off-by: KOSAKI Motohiro
    Signed-off-by: Frederic Weisbecker

    Zhaolei
     

07 Apr, 2009

1 commit


26 Mar, 2009

1 commit

  • Empty lines separate cpus stat. After previous
    fix(trace_stat: keep original order) applied, the empty lines
    are displayed at incorrect position.

    Signed-off-by: Lai Jiangshan
    Acked-by: Steven Rostedt
    Acked-by: Frederic Weisbecker
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Lai Jiangshan
     

25 Mar, 2009

1 commit

  • Currently, if a trace_stat user wants a handle to some private data,
    the trace_stat infrastructure does not supply a way to do that.

    This patch passes the trace_stat structure to the start function of
    the trace_stat code.

    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

13 Mar, 2009

1 commit


11 Mar, 2009

2 commits


10 Mar, 2009

1 commit


09 Mar, 2009

1 commit

  • Impact: improve workqueue tracer output

    Currently, /sys/kernel/debug/tracing/trace_stat/workqueues can display
    wrong and strange thread names.

    Why?

    Currently, ftrace has tracing_record_cmdline()/trace_find_cmdline()
    convenience function that implements a task->comm string cache.

    This can avoid unnecessary memcpy overhead and the workqueue tracer
    uses it.

    However, in general, any trace statistics feature shouldn't use
    tracing_record_cmdline() because trace statistics can display
    very old process. Then comm cache can return wrong string because
    recent process overrides the cache.

    Fortunately, workqueue trace guarantees that displayed processes
    are live. Thus we can search comm string from PID at display time.

    % cat workqueues
    # CPU INSERTED EXECUTED NAME
    # | | | |

    7 431913 431913 kondemand/7
    7 0 0 tail
    7 21 21 git
    7 0 0 ls
    7 9 9 cat
    7 832632 832632 unix_chkpwd
    7 236292 236292 ls

    Note: tail, git, ls, cat unix_chkpwd are obiously not workqueue thread.

    % cat workqueues
    # CPU INSERTED EXECUTED NAME
    # | | | |

    7 510 510 kondemand/7
    7 0 0 kmpathd/7
    7 15 15 ata/7
    7 0 0 aio/7
    7 11 11 kblockd/7
    7 1063 1063 work_on_cpu/7
    7 167 167 events/7

    Signed-off-by: KOSAKI Motohiro
    Cc: Lai Jiangshan
    Cc: Steven Rostedt
    Cc: Frederic Weisbecker
    Signed-off-by: Ingo Molnar

    KOSAKI Motohiro
     

20 Jan, 2009

1 commit

  • Impact: use percpu data instead of a global structure

    Use:

    static DEFINE_PER_CPU(struct workqueue_global_stats, all_workqueue_stat);

    instead of allocating a global structure.

    percpu data also works well on NUMA.

    Signed-off-by: Lai Jiangshan
    Signed-off-by: Steven Rostedt
    Signed-off-by: Ingo Molnar

    Lai Jiangshan
     

14 Jan, 2009

1 commit

  • Impact: new tracer

    The workqueue tracer provides some statistical informations
    about each cpu workqueue thread such as the number of the
    works inserted and executed since their creation. It can help
    to evaluate the amount of work each of them have to perform.
    For example it can help a developer to decide whether he should
    choose a per cpu workqueue instead of a singlethreaded one.

    It only traces statistical informations for now but it will probably later
    provide event tracing too.

    Such a tracer could help too, and be improved, to help rt priority sorted
    workqueue development.

    To have a snapshot of the workqueues state at any time, just do

    cat /debugfs/tracing/trace_stat/workqueues

    Ie:

    1 125 125 reiserfs/1
    1 0 0 scsi_tgtd/1
    1 0 0 aio/1
    1 0 0 ata/1
    1 114 114 kblockd/1
    1 0 0 kintegrityd/1
    1 2147 2147 events/1

    0 0 0 kpsmoused
    0 105 105 reiserfs/0
    0 0 0 scsi_tgtd/0
    0 0 0 aio/0
    0 0 0 ata_aux
    0 0 0 ata/0
    0 0 0 cqueue
    0 0 0 kacpi_notify
    0 0 0 kacpid
    0 149 149 kblockd/0
    0 0 0 kintegrityd/0
    0 1000 1000 khelper
    0 2270 2270 events/0

    Changes in V2:

    _ Drop the static array based on NR_CPU and dynamically allocate the stat array
    with num_possible_cpus() and other cpu mask facilities....
    _ Trace workqueue insertion at a bit lower level (insert_work instead of queue_work) to handle
    even the workqueue barriers.

    Signed-off-by: Frederic Weisbecker
    Signed-off-by: Steven Rostedt
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker