29 Dec, 2018

1 commit

  • This is a fix for another instance of the skid problem Milian recently
    found [1]

    The LBRs don't freeze at the exact same time as the PMI is triggered.
    The perf script brstackinsn code that dumps LBR assembler assumes that
    the last branch in the LBR leads to the sample point. But with skid
    it's possible that the CPU executes one or more branches before the
    sample, but which do not appear in the LBR.

    What happens then is either that the sample point is before the last LBR
    branch. In this case the dumper sees a negative length and ignores it.
    Or it the sample point is long after the last branch. Then the dumper
    sees a very long block and dumps it upto its block limit (16k bytes),
    which is noise in the output.

    On typical sample session this can happen regularly.

    This patch tries to detect and handle the situation. On the last block
    that is dumped by the LBR dumper we always stop on the first branch. If
    the block length is negative just scan forward to the first branch.
    Otherwise scan until a branch is found.

    The PT decoder already has a function that uses the instruction decoder
    to detect branches, so we can just reuse it here.

    Then when a terminating branch is found print an indication and stop
    dumping. This might miss a few instructions, but at least shows no
    runaway blocks.

    Signed-off-by: Andi Kleen
    Acked-by: Adrian Hunter
    Cc: Jiri Olsa
    Cc: Milian Wolff
    Link: http://lkml.kernel.org/r/20181120050617.4119-1-andi@firstfloor.org
    [ Resolved conflict with dd2e18e9ac20 ("perf tools: Support 'srccode' output") ]
    Signed-off-by: Arnaldo Carvalho de Melo

    Andi Kleen
     

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
     

16 Mar, 2017

1 commit

  • Implement printing instruction sequences as hex dump for branch stacks.

    This relies on the x86 instruction decoder used by the PT decoder to
    find the lengths of instructions to dump them individually.

    This is good enough for pattern matching.

    This allows to study hot paths for individual samples, together with
    branch misprediction and cycle count / IPC information if available (on
    Skylake systems).

    % perf record -b ...
    % perf script -F brstackinsn
    ...
    read_hpet+67:
    ffffffff9905b843 insn: 74 ea # PRED
    ffffffff9905b82f insn: 85 c9
    ffffffff9905b831 insn: 74 12
    ffffffff9905b833 insn: f3 90
    ffffffff9905b835 insn: 48 8b 0f
    ffffffff9905b838 insn: 48 89 ca
    ffffffff9905b83b insn: 48 c1 ea 20
    ffffffff9905b83f insn: 39 f2
    ffffffff9905b841 insn: 89 d0
    ffffffff9905b843 insn: 74 ea # PRED

    Only works when no special branch filters are specified.

    Occasionally the path does not reach up to the sample IP, as the LBRs
    may be frozen before executing a final jump. In this case we print a
    special message.

    The instruction dumper piggy backs on the existing infrastructure from
    the IP PT decoder.

    An earlier iteration of this patch relied on a disassembler, but this
    version only uses the existing instruction decoder.

    Committer note:

    Added hint about how to get suitable perf.data files for use with
    '-F brstackinsm':

    $ perf record usleep 1
    [ perf record: Woken up 1 times to write data ]
    [ perf record: Captured and wrote 0.018 MB perf.data (8 samples) ]
    $
    $ perf script -F brstackinsn
    Display of branch stack assembler requested, but non all-branch filter set
    Hint: run 'perf record -b ...'
    $

    Signed-off-by: Andi Kleen
    Tested-by: Arnaldo Carvalho de Melo
    Cc: Jiri Olsa
    Cc: Michael Ellerman
    Link: http://lkml.kernel.org/r/20170223234634.583-1-andi@firstfloor.org
    Signed-off-by: Arnaldo Carvalho de Melo

    Andi Kleen