Re: [PATCH] perf: Add irq and exception return branch types

[Anshuman Khandual]

On 3/6/22 00:34, Arnaldo Carvalho de Melo wrote:
> Em Mon, Feb 28, 2022 at 03:45:25PM +0000, James Clark escreveu:
>>
>> On 24/02/2022 05:36, Anshuman Khandual wrote:
>>> This expands generic branch type classification by adding two more entries
>>> there in i.e irq and exception return. Also updates the x86 implementation
>>> to process X86_BR_IRET and X86_BR_IRQ records as appropriate. This changes
>>> branch types reported to user space on x86 platform but it should not be a
>>> problem. The possible scenarios and impacts are enumerated here.
>>>
>>> --------------------------------------------------------------------------
>>> | kernel | perf tool |                     Impact                        |
>>> --------------------------------------------------------------------------
>>> |   old  |    old    |  Works as before                                  |
>>> --------------------------------------------------------------------------
>>> |   old  |    new    |  PERF_BR_UNKNOWN is processed                     |
>>> --------------------------------------------------------------------------
>>> |   new  |    old    |  PERF_BR_ERET/IRQ are blocked via old PERF_BR_MAX |
>>> --------------------------------------------------------------------------
>>> |   new  |    new    |  PERF_BR_ERET/IRQ are recognized                  |
>>> --------------------------------------------------------------------------
>>>
>>> When PERF_BR_ERET/IRQ are blocked via old PERF_BR_MAX (new kernel with old
>>> perf tool) the user space might throw up an warning complaining about some
>>> unrecognized branch types being reported, but it is expected. PERF_BR_ERET
>>> and PERF_BR_IRQ branch types will be used for BRBE implementation on arm64
>>> platform.
>>>
>>> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
>>> Cc: Ingo Molnar <mingo@xxxxxxxxxx>
>>> Cc: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>
>>> Cc: Mark Rutland <mark.rutland@xxxxxxx>
>>> Cc: Alexander Shishkin <alexander.shishkin@xxxxxxxxxxxxxxx>
>>> Cc: Jiri Olsa <jolsa@xxxxxxxxxx>
>>> Cc: Namhyung Kim <namhyung@xxxxxxxxxx>
>>> Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
>>> Cc: Will Deacon <will@xxxxxxxxxx>
>>> Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
>>> Cc: linux-perf-users@xxxxxxxxxxxxxxx
>>> Cc: linux-kernel@xxxxxxxxxxxxxxx
>>> Signed-off-by: Anshuman Khandual <anshuman.khandual@xxxxxxx>
>>> ---
>>> This applies on v5.17-rc5
>>>
>>> These two new branch types expands generic branch type classification but
>>> still leaves another three entries in 'type' field for later. Please refer
>>> a previous discussion [1] for some further context.
>>>
>>> [1] https://lore.kernel.org/all/1643348653-24367-1-git-send-email-anshuman.khandual@xxxxxxx/
>>>
>>>  arch/x86/events/intel/lbr.c           | 4 ++--
>>>  include/uapi/linux/perf_event.h       | 2 ++
> Please try to avoid lockstep development of kernel and tools/, submit
> patches to the kernel maintainers for the kernel parts, and to the perf
> tools maintainer in separate patches.

Sure, will split this patch into two i.e kernel and user space changes. I have
an updated series which has some more kernel and user space API changes. But I
am wondering if there should be just a single patch updating user space API for
all the preceding kernel changes, or there should be one user space API patch
for each corresponding kernel change ?

> 
> It is important that changes to the API are flagged, for instance via
> tools/perf/check-headers.sh so that opportunity is given for the various
> people involved in perf (u/k) development to see what is going on.

Will run the diff after the series has been applied to demonstrate all the API
changes and update that in the cover letter.