16 Jan, 2010

1 commit

  • Since they can come from another architecture with bigger
    pointers, i.e. processing a 64-bit perf.data on a 32-bit arch.

    Signed-off-by: Arnaldo Carvalho de Melo
    Cc: Frédéric Weisbecker
    Cc: Mike Galbraith
    Cc: Peter Zijlstra
    Cc: Paul Mackerras
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Arnaldo Carvalho de Melo
     

28 Dec, 2009

3 commits


16 Dec, 2009

1 commit


15 Dec, 2009

1 commit


14 Dec, 2009

7 commits


12 Dec, 2009

1 commit

  • That does all the initialization boilerplate, opening the file,
    reading the header, checking if it is valid, etc.

    And that will as well have the threads list, kmap (now) global
    variable, etc, so that we can handle two (or more) perf.data files
    describing sessions to compare.

    Signed-off-by: Arnaldo Carvalho de Melo
    Cc: Frédéric Weisbecker
    Cc: Mike Galbraith
    Cc: Peter Zijlstra
    Cc: Paul Mackerras
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Arnaldo Carvalho de Melo
     

10 Dec, 2009

1 commit

  • When we have a maximum latency reported for a task, we need a
    convenient way to find the matching location to the raw traces
    or to perf sched map that shows where the task has been
    eventually scheduled in. This gives a pointer to retrieve the
    events that occured during this max latency.

    Signed-off-by: Frederic Weisbecker
    Reviewed-by: Xiao Guangrong
    Cc: Peter Zijlstra
    Cc: Arnaldo Carvalho de Melo
    Cc: Paul Mackerras
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     

09 Dec, 2009

1 commit

  • In current code, task's execute time is got by reading
    '/proc//sched' file, it's wrong if the task is created
    by pthread_create(), because every thread task has same pid.

    This way also has two demerits:

    1: 'perf sched replay' can't work if the kernel is not
    compiled with the 'CONFIG_SCHED_DEBUG' option

    2: perf tool should depend on proc file system

    So, this patch uses PERF_COUNT_SW_TASK_CLOCK to get task's
    execution time instead of reading /proc file.

    Changelog v2 -> v3:
    use PERF_COUNT_SW_TASK_CLOCK instead of rusage() as Ingo's
    suggestion

    Reported-by: Torok Edwin
    Signed-off-by: Xiao Guangrong
    Cc: Xiao Guangrong
    Cc: Peter Zijlstra
    Cc: Frederic Weisbecker
    Cc: Paul Mackerras
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Xiao Guangrong
     

07 Dec, 2009

4 commits

  • raw->size is not used, this patch just cleans it up.

    Signed-off-by: Xiao Guangrong
    Cc: Frederic Weisbecker
    Cc: Paul Mackerras
    Cc: OGAWA Hirofumi
    Cc: Peter Zijlstra
    Cc: Li Zefan
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Xiao Guangrong
     
  • We use 'data.raw_data' parameter to call process_raw_event(),
    but data.raw_data buffer not include data size. it can make perf
    tool crash.

    This bug was introduced by commit 180f95e29a ("perf: Make common
    SAMPLE_EVENT parser").

    Signed-off-by: Xiao Guangrong
    Cc: Pekka Enberg
    Cc: Eduard - Gabriel Munteanu
    Cc: Frederic Weisbecker
    Cc: Paul Mackerras
    Cc: OGAWA Hirofumi
    Cc: Peter Zijlstra
    Cc: Li Zefan
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Xiao Guangrong
     
  • If we use 'perf sched trace', it will call symbol__init() again,
    and can lead to a perf tool crash:

    [root@localhost perf]# ./perf sched trace
    *** glibc detected *** ./perf: free(): invalid next size (normal): 0x094c1898 ***
    ======= Backtrace: =========
    /lib/libc.so.6[0xb7602404]
    /lib/libc.so.6(cfree+0x96)[0xb76043b6]
    ./perf[0x80730fe]
    ./perf[0x8074c97]
    ./perf[0x805eb59]
    ./perf[0x80536fd]
    ./perf[0x804b618]
    ./perf[0x804bdc3]
    /lib/libc.so.6(__libc_start_main+0xe5)[0xb75a9735]
    ./perf[0x804af81]
    ======= Memory map: ========
    08048000-08158000 r-xp 00000000 fe:00 556831 /home/eric/....
    08158000-08168000 rw-p 0010f000 fe:00 556831 /home/eric/...
    08168000-085fe000 rw-p 00000000 00:00 0
    094ab000-094cc000 rw-p 00000000 00:00 0 [heap]

    Signed-off-by: Xiao Guangrong
    LKML-Reference:
    Cc: Peter Zijlstra
    Cc: Mike Galbraith
    Cc: Paul Mackerras
    Cc: Arnaldo Carvalho de Melo
    Cc: Frederic Weisbecker
    Signed-off-by: Ingo Molnar

    Xiao Guangrong
     
  • Currently, sample event data is parsed for each commands, and it
    is assuming that the data is not including other data. (E.g.
    timechart, trace, etc. can't parse the event if it has
    PERF_SAMPLE_CALLCHAIN)

    So, even if we record the superset data for multiple commands at
    a time, commands can't parse. etc.

    To fix it, this makes common sample event parser, and use it to
    parse sample event correctly. (PERF_SAMPLE_READ is unsupported
    for now though, it seems to be not using.)

    Signed-off-by: OGAWA Hirofumi
    Cc: Peter Zijlstra
    Cc: Paul Mackerras
    Cc: Arnaldo Carvalho de Melo
    Cc: Frederic Weisbecker
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    OGAWA Hirofumi
     

28 Nov, 2009

1 commit

  • While implementing event__preprocess_sample, that will do all of
    the symbol lookup in one convenient function, I noticed that
    util/process_event.[ch] were not being used at all, then started
    looking if there were other functions that could be shared
    and...

    All those functions really don't need to receive offset + head,
    the only thing they did was common to all of them, so do it at
    one place instead.

    Stats about number of each type of event processed now is done
    in a central place.

    Signed-off-by: Arnaldo Carvalho de Melo
    Cc: Frédéric Weisbecker
    Cc: John Kacur
    Cc: Mike Galbraith
    Cc: Peter Zijlstra
    Cc: Paul Mackerras
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Arnaldo Carvalho de Melo
     

24 Nov, 2009

3 commits

  • This way we type less characters and it looks more like the
    kzalloc kernel counterpart.

    Signed-off-by: Arnaldo Carvalho de Melo
    Cc: Frédéric Weisbecker
    Cc: Mike Galbraith
    Cc: Peter Zijlstra
    Cc: Paul Mackerras
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Arnaldo Carvalho de Melo
     
  • And also express its configuration toggles via a struct.

    Now all one has to do is to call symbol__init(NULL) if the
    defaults are OK, or pass a struct symbol_conf pointer with the
    desired configuration.

    If a tool uses kernel_maps__find_symbol() to look at the kernel
    and modules mappings for a symbol but didn't call symbol__init()
    first, that will generate a one time warning too, alerting the
    subcommand developer that symbol__init() must be called.

    Signed-off-by: Arnaldo Carvalho de Melo
    Cc: Frédéric Weisbecker
    Cc: Mike Galbraith
    Cc: Peter Zijlstra
    Cc: Paul Mackerras
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Arnaldo Carvalho de Melo
     
  • Now that we can check the buildid to see if it really matches,
    this can be done safely:

    vmlinux
    /boot/vmlinux
    /boot/vmlinux-
    /lib/modules//build/vmlinux
    /usr/lib/debug/lib/modules/%s/vmlinux

    More can be added - if you know about distros that put the
    vmlinux somewhere else please let us know.

    Signed-off-by: Arnaldo Carvalho de Melo
    Cc: Frédéric Weisbecker
    Cc: Mike Galbraith
    Cc: Peter Zijlstra
    Cc: Paul Mackerras
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Arnaldo Carvalho de Melo
     

02 Nov, 2009

1 commit

  • Before we were storing this in the DSO, but in fact this is a
    property of the 'symbol' class, not something that will vary
    among DSOs, so move it to a global variable and initialize it
    using the existing symbol__init routine.

    Signed-off-by: Arnaldo Carvalho de Melo
    Cc: Frederic Weisbecker
    Cc: Peter Zijlstra
    Cc: Paul Mackerras
    Cc: Mike Galbraith
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Arnaldo Carvalho de Melo
     

23 Oct, 2009

1 commit

  • We were using eprintf in some places, that looks at a global
    'verbose' level, and at other places passing a 'v' parameter to
    specify the verbosity level, unify it by introducing
    pr_{err,warning,debug,etc}, just like in the kernel.

    Signed-off-by: Arnaldo Carvalho de Melo
    Cc: Frederic Weisbecker
    Cc: Peter Zijlstra
    Cc: Paul Mackerras
    Cc: Mike Galbraith
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Arnaldo Carvalho de Melo
     

19 Oct, 2009

1 commit


17 Oct, 2009

1 commit

  • In each case, if the NULL test on thread is needed, then the
    dereference should be after the NULL test.

    A simplified version of the semantic match that detects this
    problem is as follows (http://coccinelle.lip6.fr/):

    //
    @match exists@
    expression x, E;
    identifier fld;
    @@

    * x->fld
    ... when != \(x = E\|&x\)
    * x == NULL
    //

    Signed-off-by: Julia Lawall
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Julia Lawall
     

15 Oct, 2009

1 commit


13 Oct, 2009

1 commit


12 Oct, 2009

2 commits

  • To refresh, trying to sched record only one CPU results in bogus
    latencies as below.

    I fixed^Wmade it stop doing the bad thing today, by
    following task migration events properly.

    Before:

    marge:/root/tmp # taskset -c 1 perf sched record -C 0 -- sleep 10
    marge:/root/tmp # perf sched lat
    -----------------------------------------------------------------------------------------
    Task | Runtime ms | Switches | Average delay ms | Maximum delay ms |
    -----------------------------------------------------------------------------------------
    Xorg:4943 | 1.290 ms | 1 | avg: 1670.132 ms | max: 1670.132 ms |
    hald-addon-stor:3569 | 0.091 ms | 3 | avg: 658.609 ms | max: 1975.797 ms |
    hald-addon-stor:3573 | 0.209 ms | 4 | avg: 499.138 ms | max: 1990.565 ms |
    audispd:4270 | 0.012 ms | 1 | avg: 0.015 ms | max: 0.015 ms |
    ....

    marge:/root/tmp # perf sched trace|grep 'Xorg:4943'
    swapper-0 [000] 401.184013288: sched_stat_runtime: task: Xorg:4943 runtime: 1233188 [ns], vruntime: 19105169779 [ns]
    rt2870TimerQHan-4947 [000] 402.854140127: sched_stat_wait: task: Xorg:4943 wait: 580073 [ns]
    rt2870TimerQHan-4947 [000] 402.854141770: sched_migrate_task: task Xorg:4943 [140] from: 1 to: 0
    rt2870TimerQHan-4947 [000] 402.854143854: sched_stat_wait: task: Xorg:4943 wait: 0 [ns]
    rt2870TimerQHan-4947 [000] 402.854145397: sched_switch: task rt2870TimerQHan:4947 [140] (D) ==> Xorg:4943 [140]
    Xorg-4943 [000] 402.854193133: sched_stat_runtime: task: Xorg:4943 runtime: 56546 [ns], vruntime: 11766332500 [ns]
    Xorg-4943 [000] 402.854196842: sched_switch: task Xorg:4943 [140] (S) ==> swapper:0 [140]

    After:

    marge:/root/tmp # taskset -c 1 perf sched record -C 0 -- sleep 10
    marge:/root/tmp # perf sched lat
    -----------------------------------------------------------------------------------------
    Task | Runtime ms | Switches | Average delay ms | Maximum delay ms |
    -----------------------------------------------------------------------------------------
    amarokapp:11150 | 271.297 ms | 878 | avg: 0.130 ms | max: 1.057 ms |
    konsole:5965 | 1.370 ms | 12 | avg: 0.092 ms | max: 0.855 ms |
    Xorg:4943 | 179.980 ms | 1109 | avg: 0.087 ms | max: 1.206 ms |
    hald-addon-stor:3574 | 0.212 ms | 9 | avg: 0.040 ms | max: 0.169 ms |
    hald-addon-stor:3570 | 0.223 ms | 9 | avg: 0.037 ms | max: 0.223 ms |
    klauncher:5864 | 0.550 ms | 8 | avg: 0.032 ms | max: 0.048 ms |

    The 'Maximum delay ms' results are now sane.

    Signed-off-by: Mike Galbraith
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Mike Galbraith
     
  • The following perf build warnings/errors in function
    argument types:

    builtin-sched.c:1894: warning: passing argument 1 of 'sort_dimension__add' discards qualifiers from pointer target type
    util/trace-event-parse.c:685: warning: passing argument 2 of 'read_expected' discards qualifiers from pointer target type
    util/trace-event-parse.c:741: warning: passing argument 4 of 'test_type_token' discards qualifiers from pointer target type
    util/trace-event-parse.c:706: warning: passing argument 2 of 'read_expected_item' discards qualifiers from pointer target type

    ... trigger because older GCC is not able to prove that
    sort_dimension__add() does not change the string.

    Some goes for test_type_token().

    Fix this by improving type consistency.

    Signed-off-by: Randy Dunlap
    Acked-by: Frederic Weisbecker
    Acked-by: Peter Zijlstra
    Cc: Paul Mackerras
    LKML-Reference:
    [ Also remove ugly type cast now unnecessary. ]
    Signed-off-by: Ingo Molnar

    Randy Dunlap
     

09 Oct, 2009

1 commit

  • This reverts commit 9a92b479b2f088ee2d3194243f4c8e59b1b8c9c2 ("perf
    tools: Improve thread comm resolution in perf sched") and fixes the
    real bug.

    The bug was elsewhere:

    We are failing to resolve thread names in perf sched because the
    table of threads we are building, on top of comm events, has a per
    process granularity. But perf sched, unlike the other perf tools,
    needs a per thread granularity as we are profiling every tasks
    individually.

    So fix it by building our threads table using the tid instead of
    the pid as the thread identifier.

    v2: Revert the previous fix - it is not really needed

    Signed-off-by: Frederic Weisbecker
    Cc: Peter Zijlstra
    Cc: Arnaldo Carvalho de Melo
    Cc: Mike Galbraith
    Cc: Paul Mackerras
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     

08 Oct, 2009

2 commits

  • When we get sched traces that involve a task that was already
    created before opening the event, we won't have the comm event for
    it.

    So if we can't find the comm event for a given thread, we look at
    the traces that may contain these informations.

    Before:

    ata/1:371 | 0.000 ms | 1 | avg: 3988.693 ms | max: 3988.693 ms |
    kondemand/1:421 | 0.096 ms | 3 | avg: 345.346 ms | max: 1035.989 ms |
    kondemand/0:420 | 0.025 ms | 3 | avg: 421.332 ms | max: 964.014 ms |
    :5124:5124 | 0.103 ms | 5 | avg: 74.082 ms | max: 277.194 ms |
    :6244:6244 | 0.691 ms | 9 | avg: 125.655 ms | max: 271.306 ms |
    firefox:5080 | 0.924 ms | 5 | avg: 53.833 ms | max: 257.828 ms |
    npviewer.bin:6225 | 21.871 ms | 53 | avg: 22.462 ms | max: 220.835 ms |
    :6245:6245 | 9.631 ms | 21 | avg: 41.864 ms | max: 213.349 ms |

    After:

    ata/1:371 | 0.000 ms | 1 | avg: 3988.693 ms | max: 3988.693 ms |
    kondemand/1:421 | 0.096 ms | 3 | avg: 345.346 ms | max: 1035.989 ms |
    kondemand/0:420 | 0.025 ms | 3 | avg: 421.332 ms | max: 964.014 ms |
    firefox:5124 | 0.103 ms | 5 | avg: 74.082 ms | max: 277.194 ms |
    npviewer.bin:6244 | 0.691 ms | 9 | avg: 125.655 ms | max: 271.306 ms |
    firefox:5080 | 0.924 ms | 5 | avg: 53.833 ms | max: 257.828 ms |
    npviewer.bin:6225 | 21.871 ms | 53 | avg: 22.462 ms | max: 220.835 ms |
    npviewer.bin:6245 | 9.631 ms | 21 | avg: 41.864 ms | max: 213.349 ms |

    Signed-off-by: Frederic Weisbecker
    Cc: Peter Zijlstra
    Cc: Arnaldo Carvalho de Melo
    Cc: Mike Galbraith
    Cc: Paul Mackerras
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     
  • This librarizes the perf.data file mapping and handling in various
    perf tools, roughly reducing the amount of code and fixing the
    places that mmap from beginning of the file whereas we want to mmap
    from the beginning of the data, leading to page fault because the
    mmap window is too small since the trace info are written in the
    file too.

    TODO:

    - convert perf timechart too

    Signed-off-by: Frederic Weisbecker
    Cc: Peter Zijlstra
    Cc: Arnaldo Carvalho de Melo
    Cc: Mike Galbraith
    Cc: Paul Mackerras
    Cc: Arjan van de Ven
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     

07 Oct, 2009

1 commit

  • This drops the trace.info file and move its contents into the
    common perf.data file.

    This is done by creating a new trace_info section into this file. A
    user of perf headers needs to call perf_header__set_trace_info() to
    save the trace meta informations into the perf.data file.

    A file created by perf after his patch is unsupported by previous
    version because the size of the headers have increased.

    That said, it's two new fields that have been added in the end of
    the headers, and those could be ignored by previous versions if
    they just handled the dynamic header size and then ignore the
    unknow part. The offsets guarantee the compatibility. We'll do a
    -stable fix for that.

    But current previous versions handle the header size using its
    static size, not dynamic, then it's not backward compatible with
    trace records.

    Signed-off-by: Frederic Weisbecker
    Cc: Peter Zijlstra
    Cc: Arnaldo Carvalho de Melo
    Cc: Paul Mackerras
    Cc: Mike Galbraith
    Cc: Paul Mackerras
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     

30 Sep, 2009

1 commit

  • Several variables are not used at all, cut'n'paste leftovers.

    Also check if the sample_type is RAW earlier, to avoid needless
    searches.

    Signed-off-by: Arnaldo Carvalho de Melo
    Cc: Frédéric Weisbecker
    Cc: "H. Peter Anvin"
    Cc: Peter Zijlstra
    Cc: Mike Galbraith
    Signed-off-by: Ingo Molnar

    Arnaldo Carvalho de Melo
     

21 Sep, 2009

1 commit

  • Bye-bye Performance Counters, welcome Performance Events!

    In the past few months the perfcounters subsystem has grown out its
    initial role of counting hardware events, and has become (and is
    becoming) a much broader generic event enumeration, reporting, logging,
    monitoring, analysis facility.

    Naming its core object 'perf_counter' and naming the subsystem
    'perfcounters' has become more and more of a misnomer. With pending
    code like hw-breakpoints support the 'counter' name is less and
    less appropriate.

    All in one, we've decided to rename the subsystem to 'performance
    events' and to propagate this rename through all fields, variables
    and API names. (in an ABI compatible fashion)

    The word 'event' is also a bit shorter than 'counter' - which makes
    it slightly more convenient to write/handle as well.

    Thanks goes to Stephane Eranian who first observed this misnomer and
    suggested a rename.

    User-space tooling and ABI compatibility is not affected - this patch
    should be function-invariant. (Also, defconfigs were not touched to
    keep the size down.)

    This patch has been generated via the following script:

    FILES=$(find * -type f | grep -vE 'oprofile|[^K]config')

    sed -i \
    -e 's/PERF_EVENT_/PERF_RECORD_/g' \
    -e 's/PERF_COUNTER/PERF_EVENT/g' \
    -e 's/perf_counter/perf_event/g' \
    -e 's/nb_counters/nb_events/g' \
    -e 's/swcounter/swevent/g' \
    -e 's/tpcounter_event/tp_event/g' \
    $FILES

    for N in $(find . -name perf_counter.[ch]); do
    M=$(echo $N | sed 's/perf_counter/perf_event/g')
    mv $N $M
    done

    FILES=$(find . -name perf_event.*)

    sed -i \
    -e 's/COUNTER_MASK/REG_MASK/g' \
    -e 's/COUNTER/EVENT/g' \
    -e 's/\/event_id/g' \
    -e 's/counter/event/g' \
    -e 's/Counter/Event/g' \
    $FILES

    ... to keep it as correct as possible. This script can also be
    used by anyone who has pending perfcounters patches - it converts
    a Linux kernel tree over to the new naming. We tried to time this
    change to the point in time where the amount of pending patches
    is the smallest: the end of the merge window.

    Namespace clashes were fixed up in a preparatory patch - and some
    stylistic fallout will be fixed up in a subsequent patch.

    ( NOTE: 'counters' are still the proper terminology when we deal
    with hardware registers - and these sed scripts are a bit
    over-eager in renaming them. I've undone some of that, but
    in case there's something left where 'counter' would be
    better than 'event' we can undo that on an individual basis
    instead of touching an otherwise nicely automated patch. )

    Suggested-by: Stephane Eranian
    Acked-by: Peter Zijlstra
    Acked-by: Paul Mackerras
    Reviewed-by: Arjan van de Ven
    Cc: Mike Galbraith
    Cc: Arnaldo Carvalho de Melo
    Cc: Frederic Weisbecker
    Cc: Steven Rostedt
    Cc: Benjamin Herrenschmidt
    Cc: David Howells
    Cc: Kyle McMartin
    Cc: Martin Schwidefsky
    Cc: "David S. Miller"
    Cc: Thomas Gleixner
    Cc: "H. Peter Anvin"
    Cc:
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Ingo Molnar
     

18 Sep, 2009

2 commits

  • perf sched record passes unparsed args on to perf record, so
    specifying an output file via perf sched record -o FILE (cmd) just
    works. Ergo, provide an option to specify input file as well.

    Also add the missing 'map' command to help.

    Signed-off-by: Mike Galbraith
    Acked-by: Peter Zijlstra
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Mike Galbraith
     
  • For 'perf sched map' output, determine max_cpu automatically,
    instead of the static default of 15.

    [ v2: use sysconf() pointed out by Arjan van de Ven ]

    Cc: Peter Zijlstra
    Cc: Mike Galbraith
    Cc: Paul Mackerras
    Cc: Arnaldo Carvalho de Melo
    Cc: Frederic Weisbecker
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Ingo Molnar