• Namhyung Kim's avatar
    perf lock contention: Revise needs_callstack() condition · 0fba2265
    Namhyung Kim authored
    It needs callstacks for two reasons:
    
     * for stack aggregation mode, the map key is the stack id and it can
       also show the full stack traces when -v is used
    
     * for other aggregation modes, the stack filter can be used to limit
       lock contentions from known call paths
    
    The -v option is meaningful (in terms of stack trace) only for stack
    aggregation mode, so it should not set the save_callstack for other
    mode like with -t or -l options.
    
    I've noticed this with the following command line:
    
      $ sudo ./perf lock con -ablv -E 3 -M 16 -- ./perf bench sched messaging
      ...
       contended   total wait     max wait     avg wait            address   symbol
    
              88      4.59 ms    108.07 us     52.13 us   ffff935757f46ec0    (spinlock)
              33    905.22 us     73.67 us     27.43 us   ffff935757f41700    (spinlock)
              28    703.69 us     79.28 us     25.13 us   ffff938a3d9b0c80   rq_lock (spinlock)
    
      === output for debug ===
    
      bad: 12272, total: 12421
      bad rate: 98.80 %
      histogram of failure reasons
             task: 8285
            stack: 3987    <---------- here
             time: 0
             data: 0
    
    It should not have any failure on stacks since it doesn't use it.
    No functional change intended.
    Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
    Acked-by: default avatarIan Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Hao Luo <haoluo@google.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Juri Lelli <juri.lelli@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Song Liu <song@kernel.org>
    Cc: bpf@vger.kernel.org
    Link: https://lore.kernel.org/r/20230406210611.1622492-2-namhyung@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
    0fba2265
bpf_lock_contention.c 9.12 KB