05 Jun, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this application is free software you can redistribute it and or
    modify it under the terms of the gnu general public license as
    published by the free software foundation version 2 this application
    is distributed in the hope that it will be useful but without any
    warranty without even the implied warranty of merchantability or
    fitness for a particular purpose see the gnu general public license
    for more details

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

    has been chosen to replace the boilerplate/reference in 1 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Reviewed-by: Armijn Hemel
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190531190112.401137591@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

19 Feb, 2018

1 commit


02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

13 Jul, 2016

1 commit

  • To show how to enable a tracepoint and access its fields.

    Committer note:

    Testing it:

    # ls -l /tmp/build/perf/python/perf.so
    -rwxrwxr-x. 1 acme acme 1563256 Jul 12 16:19 /tmp/build/perf/python/perf.so
    # export PYTHONPATH=/tmp/build/perf/python/
    # tools/perf/python/tracepoint.py 2> /dev/null | head -200 | tail -10
    time 76345337296548 prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=0x0 ==> next_comm=tracepoint.py- next_pid=18479 next_prio=120
    time 76345338520479 prev_comm=gnome-shelln-b prev_pid=2186 prev_prio=120 prev_state=0x1 ==> next_comm=swapper/1 next_pid=0 next_prio=120
    time 76345337309942 prev_comm=tracepoint.py- prev_pid=18479 prev_prio=120 prev_state=0x1 ==> next_comm=swapper/0 next_pid=0 next_prio=120
    time 76345337312302 prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=0x0 ==> next_comm=tracepoint.py- next_pid=18479 next_prio=120
    time 76345337324927 prev_comm=tracepoint.py- prev_pid=18479 prev_prio=120 prev_state=0x1 ==> next_comm=swapper/0 next_pid=0 next_prio=120
    time 76345337327115 prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=0x0 ==> next_comm=tracepoint.py- next_pid=18479 next_prio=120
    time 76345338621750 prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=0x0 ==> next_comm=rcuos/2 next_pid=29 next_prio=120
    time 76345338607922 prev_comm=swapper/3 prev_pid=0 prev_prio=120 prev_state=0x0 ==> next_comm=rcu_sched next_pid=7 next_prio=120
    time 76345337338817 prev_comm=tracepoint.py- prev_pid=18479 prev_prio=120 prev_state=0x1 ==> next_comm=swapper/0 next_pid=0 next_prio=120
    time 76345338627156 prev_comm=swapper/1 prev_pid=0 prev_prio=120 prev_state=0x0 ==> next_comm=head-terminal- next_pid=18480 next_prio=120
    #
    # strip /tmp/build/perf/python/perf.so
    # ls -l /tmp/build/perf/python/perf.so
    -rwxrwxr-x. 1 acme acme 319616 Jul 12 16:25 /tmp/build/perf/python/perf.so

    Reported-and-Tested-by: Jiri Pirko
    Signed-off-by: Jiri Olsa
    Tested-by: Arnaldo Carvalho de Melo
    Cc: David Ahern
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Link: http://lkml.kernel.org/r/1468148882-10362-10-git-send-email-jolsa@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo

    Jiri Olsa
     

08 Oct, 2015

1 commit

  • To test it check tools/perf/python/twatch.py, after following the
    instructions there to enable context_switch, output looks like:

    [root@zoo linux]# tools/perf/python/twatch.py
    cpu: 1, pid: 31463, tid: 31463 { type: context_switch, next_prev_pid: 31463, next_prev_tid: 31463, switch_out: 0 }
    cpu: 2, pid: 31463, tid: 31496 { type: context_switch, next_prev_pid: 31463, next_prev_tid: 31496, switch_out: 0 }
    cpu: 2, pid: 31463, tid: 31496 { type: context_switch, next_prev_pid: 31463, next_prev_tid: 31496, switch_out: 1 }
    cpu: 3, pid: 31463, tid: 31527 { type: context_switch, next_prev_pid: 31463, next_prev_tid: 31527, switch_out: 0 }
    cpu: 1, pid: 31463, tid: 31463 { type: context_switch, next_prev_pid: 31463, next_prev_tid: 31463, switch_out: 1 }
    cpu: 3, pid: 31463, tid: 31527 { type: context_switch, next_prev_pid: 31463, next_prev_tid: 31527, switch_out: 1 }
    cpu: 1, pid: 31463, tid: 31463 { type: context_switch, next_prev_pid: 31463, next_prev_tid: 31463, switch_out: 0 }
    ^CTraceback (most recent call last):
    File "tools/perf/python/twatch.py", line 67, in
    main(context_switch = 1, thread = 31463)
    File "tools/perf/python/twatch.py", line 40, in main
    evlist.poll(timeout = -1)
    KeyboardInterrupt
    [root@zoo linux]#

    Cc: Adrian Hunter
    Cc: Borislav Petkov
    Cc: David Ahern
    Cc: Frederic Weisbecker
    Cc: Guy Streeter
    Cc: Jiri Olsa
    Cc: Namhyung Kim
    Cc: Stephane Eranian
    Cc: Wang Nan
    Link: http://lkml.kernel.org/n/tip-1ukistmpamc5z717k80ctcp2@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo

    Arnaldo Carvalho de Melo
     

29 Jul, 2015

1 commit

  • To not sample, what we want are just the PERF_RECORD_ lifetime events
    for threads, using the default, PERF_TYPE_HARDWARE +
    PERF_COUNT_HW_CYCLES and freq=1 (the default), makes perf reenable
    irq_vectors:local_timer_entry, disabling nohz, not good for some use
    cases where all we want is to get notifications when threads comes and
    goes...

    Fix it by using PERF_TYPE_SOFTWARE (no counter rotation) and
    PERF_COUNT_SW_DUMMY (created by Adrian so that we could have access to
    those PERF_RECORD_ goodies).

    Reported-by: Luiz Fernando Capitulino
    Suggested-by: Peter Zijlstra
    Cc: Adrian Hunter
    Cc: Borislav Petkov
    Cc: David Ahern
    Cc: Frederic Weisbecker
    Cc: Jaroslav Skarvada
    Cc: Jeremy Eder
    Cc: Jiri Olsa
    Cc: Namhyung Kim
    Cc: Stephane Eranian
    Link: http://lkml.kernel.org/n/tip-kfsijirfrs6xfhkcdxeoen06@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo

    Arnaldo Carvalho de Melo
     

08 Aug, 2013

1 commit


31 Jan, 2012

1 commit

  • We want to be woken up for every PERF_RECORD_ event, attr.wakeup_events
    is only for PERF_RECORD_SAMPLE, so also use attr.watermark = 1 to fix
    that.

    Suggested-by: Peter Zijlstra
    Cc: David Ahern
    Cc: Frederic Weisbecker
    Cc: Mike Galbraith
    Cc: Paul Mackerras
    Cc: Peter Zijlstra
    Cc: Stephane Eranian
    Link: http://lkml.kernel.org/n/tip-v3lnpwgrr8mllcr3ntduuqvc@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo

    Arnaldo Carvalho de Melo
     

31 Jan, 2011

1 commit

  • So that we don't have to pass it around to the several methods that
    needs it, simplifying usage.

    There is one case where we don't have the thread/cpu map in advance,
    which is in the parsing routines used by top, stat, record, that we have
    to wait till all options are parsed to know if a cpu or thread list was
    passed to then create those maps.

    For that case consolidate the cpu and thread map creation via
    perf_evlist__create_maps() out of the code in top and record, while also
    providing a perf_evlist__set_maps() for cases where multiple evlists
    share maps or for when maps that represent CPU sockets, for instance,
    get crafted out of topology information or subsets of threads in a
    particular application are to be monitored, providing more granularity
    in specifying which cpus and threads to monitor.

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

    Arnaldo Carvalho de Melo
     

30 Jan, 2011

1 commit

  • First clarifying that this kind of binding is not a replacement or an
    equivalent to the 'perf script' way of using python with perf.

    The 'perf script' way is to process events and look at a given script
    for some python function that matches the events to pass each event for
    processing.

    This is a python module, i.e. everything is driven from the python
    script, that merely uses "import perf" or "from perf import".

    perf script is focused on tracepoints, this binding is focused on profiling as
    an initial target. More work is needed to make available tracepoint specific
    variables as event variables accessible via this binding.

    There is one example of such usage model, in
    tools/perf/python/twatch.py, a tool to watch "cycles" events together
    with task (fork, exit) and comm perf events.

    For now, due to me not being able to grok how python distutils cope with
    building C extensions outside the sources dir the install target just
    builds it, I'm using it as:

    [root@emilia linux]# export PYTHONPATH=~acme/git/build/perf/lib.linux-x86_64-2.6/
    [root@emilia linux]# tools/perf/python/twatch.py
    cpu: 4, pid: 30126, tid: 30126 { type: mmap, pid: 30126, tid: 30126, start: 0x4, length: 0x82e9ca03, offset: 0, filename: }
    cpu: 6, pid: 47, tid: 47 { type: mmap, pid: 47, tid: 47, start: 0x6, length: 0xbef87c36, offset: 0, filename: }
    cpu: 1, pid: 0, tid: 0 { type: mmap, pid: 0, tid: 0, start: 0x1, length: 0x775d1904, offset: 0, filename: }
    cpu: 7, pid: 0, tid: 0 { type: mmap, pid: 0, tid: 0, start: 0x7, length: 0xc750aeb6, offset: 0, filename: }
    cpu: 5, pid: 2255, tid: 2255 { type: mmap, pid: 2255, tid: 2255, start: 0x5, length: 0x76669635, offset: 0, filename: }
    cpu: 0, pid: 0, tid: 0 { type: mmap, pid: 0, tid: 0, start: 0, length: 0x6422ef6b, offset: 0, filename: }
    cpu: 2, pid: 2255, tid: 2255 { type: mmap, pid: 2255, tid: 2255, start: 0x2, length: 0xe078757a, offset: 0, filename: }
    cpu: 1, pid: 5769, tid: 5769 { type: fork, pid: 30127, ppid: 5769, tid: 30127, ptid: 5769, time: 103893991270534}
    cpu: 6, pid: 30127, tid: 30127 { type: comm, pid: 30127, tid: 30127, comm: ls }
    cpu: 6, pid: 30127, tid: 30127 { type: exit, pid: 30127, ppid: 30127, tid: 30127, ptid: 30127, time: 103893993273024}

    The first 8 mmap events in this 8 way machine are a mistery that is still being
    investigated.

    More of the tools/perf/util/ APIs will be exposed via this python binding as
    the need arises. For now the focus is on creating events and processing them,
    symbol resolution is an obvious next step, with tracepoint variables as a close
    second step.

    Cc: Clark Williams
    Cc: Frederic Weisbecker
    Cc: Ingo Molnar
    Cc: Mike Galbraith
    Cc: Paul Mackerras
    Cc: Peter Zijlstra
    Cc: Stephane Eranian
    Cc: Tom Zanussi
    LKML-Reference:
    Signed-off-by: Arnaldo Carvalho de Melo

    Arnaldo Carvalho de Melo