lkml.org 
[lkml]   [2022]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] perf: Add irq and exception return branch types
From


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@infradead.org>
>>> Cc: Ingo Molnar <mingo@redhat.com>
>>> Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
>>> Cc: Jiri Olsa <jolsa@redhat.com>
>>> Cc: Namhyung Kim <namhyung@kernel.org>
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> Cc: Will Deacon <will@kernel.org>
>>> Cc: linux-arm-kernel@lists.infradead.org
>>> Cc: linux-perf-users@vger.kernel.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>>> ---
>>> 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@arm.com/
>>>
>>> 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.

\
 
 \ /
  Last update: 2022-03-08 04:21    [W:0.045 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site