Re: [PATCH V7 00/18] Add data type profiling support for powerpc
Patchset looks fine to me.
Tested-by: Kajol Jain
Reviewed-by: Kajol Jain
Thanks,
Kajol Jain
On 7/13/24 22:25, Athira Rajeev wrote:
> The patchset from Namhyung added support for data type profiling
> in perf tool. This enabled support to associate PMU samples to data
> types they refer using DWARF debug information. With the upstream
> perf, currently it possible to run perf report or perf annotate to
> view the data type information on x86.
>
> Initial patchset posted here had changes need to enable data type
> profiling support for powerpc.
>
> https://lore.kernel.org/all/6e09dc28-4a2e-49d8-a2b5-ffb3396a9...@csgroup.eu/T/
>
> Main change were:
> 1. powerpc instruction nmemonic table to associate load/store
> instructions with move_ops which is use to identify if instruction
> is a memory access one.
> 2. To get register number and access offset from the given
> instruction, code uses fields from "struct arch" -> objump.
> Added entry for powerpc here.
> 3. A get_arch_regnum to return register number from the
> register name string.
>
> But the apporach used in the initial patchset used parsing of
> disassembled code which the current perf tool implementation does.
>
> Example: lwz r10,0(r9)
>
> This line "lwz r10,0(r9)" is parsed to extract instruction name,
> registers names and offset. Also to find whether there is a memory
> reference in the operands, "memory_ref_char" field of objdump is used.
> For x86, "(" is used as memory_ref_char to tackle instructions of the
> form "mov (%rax), %rcx".
>
> In case of powerpc, not all instructions using "(" are the only memory
> instructions. Example, above instruction can also be of extended form (X
> form) "lwzx r10,0,r19". Inorder to easy identify the instruction category
> and extract the source/target registers, second patchset added support to use
> raw instruction. With raw instruction, macros are added to extract opcode
> and register fields.
> Link to second patchset:
> https://lore.kernel.org/all/20240506121906.76639-1-atraj...@linux.vnet.ibm.com/
>
> Example representation using --show-raw-insn in objdump gives result:
>
> 38 01 81 e8 ld r4,312(r1)
>
> Here "38 01 81 e8" is the raw instruction representation. In powerpc,
> this translates to instruction form: "ld RT,DS(RA)" and binary code
> as:
> _
> | 58 | RT | RA | DS | |
> -
> 06 1116 30 31
>
> Second patchset used "objdump" again to read the raw instruction.
> But since there is no need to disassemble and binary code can be read
> directly from the DSO, third patchset (ie this patchset) uses below
> apporach. The apporach preferred in powerpc to parse sample for data
> type profiling in V3 patchset is:
> - Read directly from DSO using dso__data_read_offset
> - If that fails for any case, fallback to using libcapstone
> - If libcapstone is not supported, approach will use objdump
>
> Patchset adds support to pick the opcode and reg fields from this
> raw/binary instruction code. This approach came in from review comment
> by Segher Boessenkool and Christophe for the initial patchset.
>
> Apart from that, instruction tracking is enabled for powerpc and
> support function is added to find variables defined as registers
> Example, in powerpc, below two registers are
> defined to represent variable:
> 1. r13: represents local_paca
> register struct paca_struct *local_paca asm("r13");
>
> 2. r1: represents stack_pointer
> register void *__stack_pointer asm("r1");
>
> These are handled in this patchset.
>
> - Patch 1 is to rearrange register state type structures to header file
> so that it can referred from other arch specific files
> - Patch 2 is to make instruction tracking as a callback to"struct arch"
> so that it can be implemented by other archs easily and defined in arch
> specific files
> - Patch 3 is to handle state type regs array size for x86 and powerpc
> - Patch 4 adds support to capture and parse raw instruction in powerpc
> using dso__data_read_offset utility
> - Patch 4 also adds logic to support using objdump when doing default "perf
> report" or "perf annotate" since it that needs disassembled instruction.
> - Patch 5 adds disasm_line__parse to parse raw instruction for powerpc
> - Patch 6 update parameters for reg extract functions to use raw
> instruction on powerpc
> - Patch 7 updates ins__find to carry raw_insn and also adds parse
> callback for memory instructions for powerpc
> - Patch 8 add support to identify memory instructions of opcode 31 in
> powerpc
> - Patch 9 adds more instructions to support instruction tracking in powerpc
> - Patch 10 and 11 handles instruction tracking for powerpc.
> - Patch 12, 13 and 14 add support to use libcapstone in powerpc
> - Patch 15 and patch 16 handles support to find global register variables
> - PAtch 17 updates data type compare functions data_type_cmp and
> sort__typeoff_sort to include
Re: [PATCH V6 00/18] Add data type profiling support for powerpc
On 7/12/24 09:14, Athira Rajeev wrote:
>
>
>> On 7 Jul 2024, at 8:14 PM, Athira Rajeev wrote:
>>
>> The patchset from Namhyung added support for data type profiling
>> in perf tool. This enabled support to associate PMU samples to data
>> types they refer using DWARF debug information. With the upstream
>> perf, currently it possible to run perf report or perf annotate to
>> view the data type information on x86.
>>
>> Initial patchset posted here had changes need to enable data type
>> profiling support for powerpc.
>>
>
> Hi Namhyung,
>
> Requesting for review on this V6 patchset. I have addressed review comments
> from V5.
> If the patchset looks good, can you please pull this in.
>
> Thanks
> Athira
Patches looks fine to me. Also tested in powerpc box.
Reviewed-by : Kajol Jain
Tested-by : Kajol Jain
Thanks,
Kajol Jain
>> https://lore.kernel.org/all/6e09dc28-4a2e-49d8-a2b5-ffb3396a9...@csgroup.eu/T/
>>
>> Main change were:
>> 1. powerpc instruction nmemonic table to associate load/store
>> instructions with move_ops which is use to identify if instruction
>> is a memory access one.
>> 2. To get register number and access offset from the given
>> instruction, code uses fields from "struct arch" -> objump.
>> Added entry for powerpc here.
>> 3. A get_arch_regnum to return register number from the
>> register name string.
>>
>> But the apporach used in the initial patchset used parsing of
>> disassembled code which the current perf tool implementation does.
>>
>> Example: lwz r10,0(r9)
>>
>> This line "lwz r10,0(r9)" is parsed to extract instruction name,
>> registers names and offset. Also to find whether there is a memory
>> reference in the operands, "memory_ref_char" field of objdump is used.
>> For x86, "(" is used as memory_ref_char to tackle instructions of the
>> form "mov (%rax), %rcx".
>>
>> In case of powerpc, not all instructions using "(" are the only memory
>> instructions. Example, above instruction can also be of extended form (X
>> form) "lwzx r10,0,r19". Inorder to easy identify the instruction category
>> and extract the source/target registers, second patchset added support to use
>> raw instruction. With raw instruction, macros are added to extract opcode
>> and register fields.
>> Link to second patchset:
>> https://lore.kernel.org/all/20240506121906.76639-1-atraj...@linux.vnet.ibm.com/
>>
>> Example representation using --show-raw-insn in objdump gives result:
>>
>> 38 01 81 e8 ld r4,312(r1)
>>
>> Here "38 01 81 e8" is the raw instruction representation. In powerpc,
>> this translates to instruction form: "ld RT,DS(RA)" and binary code
>> as:
>> _
>> | 58 | RT | RA | DS | |
>> -
>> 06 1116 30 31
>>
>> Second patchset used "objdump" again to read the raw instruction.
>> But since there is no need to disassemble and binary code can be read
>> directly from the DSO, third patchset (ie this patchset) uses below
>> apporach. The apporach preferred in powerpc to parse sample for data
>> type profiling in V3 patchset is:
>> - Read directly from DSO using dso__data_read_offset
>> - If that fails for any case, fallback to using libcapstone
>> - If libcapstone is not supported, approach will use objdump
>>
>> Patchset adds support to pick the opcode and reg fields from this
>> raw/binary instruction code. This approach came in from review comment
>> by Segher Boessenkool and Christophe for the initial patchset.
>>
>> Apart from that, instruction tracking is enabled for powerpc and
>> support function is added to find variables defined as registers
>> Example, in powerpc, below two registers are
>> defined to represent variable:
>> 1. r13: represents local_paca
>> register struct paca_struct *local_paca asm("r13");
>>
>> 2. r1: represents stack_pointer
>> register void *__stack_pointer asm("r1");
>>
>> These are handled in this patchset.
>>
>> - Patch 1 is to rearrange register state type structures to header file
>> so that it can referred from other arch specific files
>> - Patch 2 is to make instruction tracking as a callback to"struct arch"
>> so that it can be implemented by other archs easily and defined in arch
>> specific files
>> - Patch 3 is to handle state type regs array size for x86 and powerpc
>> - Patch 4 adds support to capture and parse raw instruction in powerpc
>> using dso__data_read_offset utility
>> - Patch 4 also adds logic to support using objdump when doing default "perf
>> report" or "perf annotate" since it that needs disassembled instruction.
>> - Patch 5 adds disasm_line__parse to parse raw instruction for powerpc
>> - Patch 6 update parameters for reg extract functions to use raw
>> instruction on powerpc
>> - Patch 7 updates ins__find to carry raw_insn and also adds parse
>> callback for memory instructions for powerpc
>> - Patch 8 add support to identify memory instructions of opcode 31 in
>> powerpc
>> - Patch 9 adds
Re: [PATCH] powerpc/hv-gpci: Fix the hcall return value checks in single_gpci_request function
On 2/20/24 18:08, Michael Ellerman wrote:
> Kajol Jain writes:
>> Running event
>> hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/
>> in one of the system throws below error:
>>
>> ---Logs---
>> # perf list | grep
>> hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles
>>
>> hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=?/[Kernel
>> PMU event]
>>
>>
>> # perf stat -v -e
>> hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/
>> sleep 2
>> Using CPUID 00800200
>> Control descriptor is not initialized
>> Warning:
>> hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/
>> event is not supported by the kernel.
>> failed to read counter
>> hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/
>>
>> Performance counter stats for 'system wide':
>>
>>
>> hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/
>>
>>2.000700771 seconds time elapsed
>>
>> The above error is because of the hcall failure as required
>> permission "Enable Performance Information Collection" is not set.
>> Based on current code, single_gpci_request function did not check the
>> error type incase hcall fails and by default returns EINVAL. But we can
>> have other reasons for hcall failures like H_AUTHORITY/H_PARAMETER for which
>> we need to act accordingly.
>> Fix this issue by adding new checks in the single_gpci_request function.
>>
>> Result after fix patch changes:
>>
>> # perf stat -e
>> hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/
>> sleep 2
>> Error:
>> No permission to enable
>> hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/
>> event.
>>
>> Fixes: 220a0c609ad1 ("powerpc/perf: Add support for the hv gpci (get
>> performance counter info) interface")
>> Reported-by: Akanksha J N
>> Signed-off-by: Kajol Jain
>> ---
>> arch/powerpc/perf/hv-gpci.c | 29 +
>> 1 file changed, 25 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/powerpc/perf/hv-gpci.c b/arch/powerpc/perf/hv-gpci.c
>> index 27f18119fda1..101060facd81 100644
>> --- a/arch/powerpc/perf/hv-gpci.c
>> +++ b/arch/powerpc/perf/hv-gpci.c
>> @@ -695,7 +695,17 @@ static unsigned long single_gpci_request(u32 req, u32
>> starting_index,
>>
>> ret = plpar_hcall_norets(H_GET_PERF_COUNTER_INFO,
>> virt_to_phys(arg), HGPCI_REQ_BUFFER_SIZE);
>> -if (ret) {
>> +
>> +/*
>> + * ret value as 'H_PARAMETER' corresponds to 'GEN_BUF_TOO_SMALL',
>
> Don't we expect H_PARAMETER if any parameter value is incorrect?
>
>> + * which means that the current buffer size cannot accommodate
>> + * all the information and a partial buffer returned.
>
> I don't see how we can infer that H_PARAMETER means the buffer is too
> small and accessing the first entry is OK?
Hi Michael,
Based on getCounterInfo documentation and the name convention it uses,
we actually used H_PARAMETER to specify the buffer issue incase buffer
cannot accommodate all the data.
Hence we are using that return value in the check.
Since based on hv-gpci event counter we only want data for specific
starting index and the hv-gpci hcall actually store data starting from
given starting index in the result buffer. We can ensure that accessing
first entry will be enough.
Thanks,
Kajol Jain
>
> cheers
>
>> + * Since in this function we are only accessing data for a given
>> starting index,
>> + * we don't need to accommodate whole data and can get required count by
>> + * accessing very first entry.
>> + * Hence hcall fails only incase the ret value is other than H_SUCCESS
>> or H_PARAMETER.
>> + */
>> +if (ret && (ret != H_PARAMETER)) {
>> pr_devel("hcall failed: 0x%lx\n", ret);
>> goto out;
>> }
Re: [PATCH] perf/pmu-events/powerpc: Update json mapfile with Power11 PVR
Patch looks fine to me.
Reviewed-by: Kajol Jain
Thanks,
Kajol Jain
On 1/29/24 17:38, Madhavan Srinivasan wrote:
> Update the Power11 PVR to json mapfile to enable
> json events. Power11 is PowerISA v3.1 compliant
> and support Power10 events.
>
> Signed-off-by: Madhavan Srinivasan
> ---
> tools/perf/pmu-events/arch/powerpc/mapfile.csv | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/perf/pmu-events/arch/powerpc/mapfile.csv
> b/tools/perf/pmu-events/arch/powerpc/mapfile.csv
> index 599a588dbeb4..4d5e9138d4cc 100644
> --- a/tools/perf/pmu-events/arch/powerpc/mapfile.csv
> +++ b/tools/perf/pmu-events/arch/powerpc/mapfile.csv
> @@ -15,3 +15,4 @@
> 0x0066[[:xdigit:]]{4},1,power8,core
> 0x004e[[:xdigit:]]{4},1,power9,core
> 0x0080[[:xdigit:]]{4},1,power10,core
> +0x0082[[:xdigit:]]{4},1,power10,core
Re: [PATCH 2/2] powerpc/hv-gpxi: Fix access permission of hv-gpci interface files
On 11/17/23 04:06, Michael Ellerman wrote:
> Kajol Jain writes:
>> Fix access permission of the hv-gpci topology information
>> interface files from 0444 to 0400 (admin read only).
>
> Please explain why they should be 0400.
>
> Also typo in subject, "hv-gpxi".
Hi Michael,
Thanks for reviewing it. Will add the details in next version of the
patch.
Thanks,
Kajol Jain
>
> cheers
>
>> Fixes: 71f1c39647d8 ("powerpc/hv_gpci: Add sysfs file inside hv_gpci device
>> to show processor bus topology information")
>> Reported-by: Disha Goel
>> Signed-off-by: Kajol Jain
>> ---
>> arch/powerpc/perf/hv-gpci.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/perf/hv-gpci.c b/arch/powerpc/perf/hv-gpci.c
>> index 27f18119fda1..303d160319e8 100644
>> --- a/arch/powerpc/perf/hv-gpci.c
>> +++ b/arch/powerpc/perf/hv-gpci.c
>> @@ -890,7 +890,7 @@ static struct device_attribute
>> *sysinfo_device_attr_create(int
>> return NULL;
>>
>> sysfs_attr_init(>attr);
>> -attr->attr.mode = 0444;
>> +attr->attr.mode = 0400;
>>
>> switch (sysinfo_interface_group_index) {
>> case INTERFACE_PROCESSOR_BUS_TOPOLOGY_ATTR:
>> --
>> 2.39.3
Re: [PATCH 0/3] Fix for shellcheck issues with latest scripts in tests/shell
Patchset looks fine to me. Reviewed-by: Kajol Jain thanks, Kajol Jain On 9/29/23 09:41, Athira Rajeev wrote: > shellcheck was run on perf tool shell scripts as a pre-requisite > to include a build option for shellcheck discussed here: > https://www.spinics.net/lists/linux-perf-users/msg25553.html > > And fixes were added for the coding/formatting issues in > two patchsets: > https://lore.kernel.org/linux-perf-users/20230613164145.50488-1-atraj...@linux.vnet.ibm.com/ > https://lore.kernel.org/linux-perf-users/20230709182800.53002-1-atraj...@linux.vnet.ibm.com/ > > Three additional issues were observed and fixes are part of: > https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/log/?h=perf-tools-next > > With recent commits in perf, other three issues are observed. > shellcheck version: 0.6.0 > > With this patchset: > > for F in $(find tests/shell/ -perm -o=x -name '*.sh'); do shellcheck -S > warning $F; done > echo $? > 0 > > The changes are with recent commits ( which is mentioned in each patch) > for ock_contention, record_sideband and test_arm_coresight testcases. > The changes are made on top of: > https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/log/?h=perf-tools-next > > Athira Rajeev (3): > perf tests test_arm_coresight: Fix the shellcheck warning in latest > test_arm_coresight.sh > tools/perf/tests Ignore the shellcheck SC2046 warning in > lock_contentio > tools/perf/tests: Fix shellcheck warning in record_sideband.sh test > > tools/perf/tests/shell/lock_contention.sh| 1 + > tools/perf/tests/shell/record_sideband.sh| 2 +- > tools/perf/tests/shell/test_arm_coresight.sh | 4 ++-- > 3 files changed, 4 insertions(+), 3 deletions(-) >
Re: [PATCH V4 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section
Patch looks good to me.
Reviewed-by: Kajol Jain
Thanks,
Kajol Jain
On 9/15/23 11:07, Athira Rajeev wrote:
> The testcase "Object code reading" fails in somecases
> for "fs_something" sub test as below:
>
> Reading object code for memory address: 0xc00807f0142c
> File is: /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko
> On file address is: 0x1114cc
> Objdump command is: objdump -z -d --start-address=0x11142c
> --stop-address=0x1114ac /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko
> objdump read too few bytes: 128
> test child finished with -1
>
> This can alo be reproduced when running perf record with
> workload that exercises fs_something() code. In the test
> setup, this is exercising xfs code since root is xfs.
>
> # perf record ./a.out
> # perf report -v |grep "xfs.ko"
> 0.76% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko
> 0xc00807de5efc B [k] xlog_cil_commit
> 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko
> 0xc00807d5ae18 B [k] xfs_btree_key_offset
> 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko
> 0xc00807e11fd4 B [k] 0x00112074
>
> Here addr "0xc00807e11fd4" is not resolved. since this is a
> kernel module, its offset is from the DSO. Xfs module is loaded
> at 0xc00807d0
>
># cat /proc/modules | grep xfs
> xfs 2228224 3 - Live 0xc00807d0
>
> And size is 0x22. So its loaded between 0xc00807d0
> and 0xc00807f2. From objdump, text section is:
> text 0010f7bc 00a0 2**4
>
> Hence perf captured ip maps to 0x112074 which is:
> ( ip - start of module ) + a0
>
> This offset 0x112074 falls out .text section which is up to 0x10f7bc
> In this case for module, the address 0xc00807e11fd4 is pointing
> to stub instructions. This address range represents the module stubs
> which is allocated on module load and hence is not part of DSO offset.
>
> To address this issue in "object code reading", skip the sample if
> address falls out of text section and is within the module end.
> Use the "text_end" member of "struct dso" to do this check.
>
> To address this issue in "perf report", exploring an option of
> having stubs range as part of the /proc/kallsyms, so that perf
> report can resolve addresses in stubs range
>
> However this patch uses text_end to skip the stub range for
> Object code reading testcase.
>
> Reported-by: Disha Goel
> Signed-off-by: Athira Rajeev
> Tested-by: Disha Goel
> Reviewed-by: Adrian Hunter
> ---
> Changelog:
> v3 -> v4:
> Fixed indent in V3
>
> v2 -> v3:
> Used strtailcmp in comparison for module check and added Reviewed-by
> from Adrian, Tested-by from Disha.
>
> v1 -> v2:
> Updated comment to add description on which arch has stub and
> reason for skipping as suggested by Adrian
>
> tools/perf/tests/code-reading.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
> index ed3815163d1b..9e6e6c985840 100644
> --- a/tools/perf/tests/code-reading.c
> +++ b/tools/perf/tests/code-reading.c
> @@ -269,6 +269,16 @@ static int read_object_code(u64 addr, size_t len, u8
> cpumode,
> if (addr + len > map__end(al.map))
> len = map__end(al.map) - addr;
>
> + /*
> + * Some architectures (ex: powerpc) have stubs (trampolines) in kernel
> + * modules to manage long jumps. Check if the ip offset falls in stubs
> + * sections for kernel modules. And skip module address after text end
> + */
> + if (!strtailcmp(dso->long_name, ".ko") && al.addr > dso->text_end) {
> + pr_debug("skipping the module address %#"PRIx64" after text
> end\n", al.addr);
> + goto out;
> + }
> +
> /* Read the object code using perf */
> ret_len = dso__data_read_offset(dso,
> maps__machine(thread__maps(thread)),
> al.addr, buf1, len);
Re: [PATCH V4 1/2] tools/perf: Add text_end to "struct dso" to save .text section size
Patch looks good to me.
Reviewed-by: Kajol Jain
Thanks,
Kajol Jain
On 9/15/23 11:07, Athira Rajeev wrote:
> Update "struct dso" to include new member "text_end".
> This new field will represent the offset for end of text
> section for a dso. For elf, this value is derived as:
> sh_size (Size of section in byes) + sh_offset (Section file
> offst) of the elf header for text.
>
> For bfd, this value is derived as:
> 1. For PE file,
> section->size + ( section->vma - dso->text_offset)
> 2. Other cases:
> section->filepos (file position) + section->size (size of
> section)
>
> To resolve the address from a sample, perf looks at the
> DSO maps. In case of address from a kernel module, there
> were some address found to be not resolved. This was
> observed while running perf test for "Object code reading".
> Though the ip falls beteen the start address of the loaded
> module (perf map->start ) and end address ( perf map->end),
> it was unresolved.
>
> Example:
>
> Reading object code for memory address: 0xc00807f0142c
> File is: /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko
> On file address is: 0x1114cc
> Objdump command is: objdump -z -d --start-address=0x11142c
> --stop-address=0x1114ac /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko
> objdump read too few bytes: 128
> test child finished with -1
>
> Here, module is loaded at:
> # cat /proc/modules | grep xfs
> xfs 2228224 3 - Live 0xc00807d0
>
> From objdump for xfs module, text section is:
> text 0010f7bc 00a0 2**4
>
> Here the offset for 0xc00807f0142c ie 0x112074 falls out
> .text section which is up to 0x10f7bc.
>
> In this case for module, the address 0xc00807e11fd4 is pointing
> to stub instructions. This address range represents the module stubs
> which is allocated on module load and hence is not part of DSO offset.
>
> To identify such address, which falls out of text
> section and within module end, added the new field "text_end" to
> "struct dso".
>
> Reported-by: Disha Goel
> Signed-off-by: Athira Rajeev
> Reviewed-by: Adrian Hunter
> ---
> Changelog:
> v2 -> v3:
> Added Reviewed-by from Adrian
>
> v1 -> v2:
> Added text_end for bfd also by updating dso__load_bfd_symbols
> as suggested by Adrian.
>
> tools/perf/util/dso.h| 1 +
> tools/perf/util/symbol-elf.c | 4 +++-
> tools/perf/util/symbol.c | 2 ++
> 3 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
> index b41c9782c754..70fe0fe69bef 100644
> --- a/tools/perf/util/dso.h
> +++ b/tools/perf/util/dso.h
> @@ -181,6 +181,7 @@ struct dso {
> u8 rel;
> struct build_id bid;
> u64 text_offset;
> + u64 text_end;
> const char *short_name;
> const char *long_name;
> u16 long_name_len;
> diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
> index 95e99c332d7e..9e7eeaf616b8 100644
> --- a/tools/perf/util/symbol-elf.c
> +++ b/tools/perf/util/symbol-elf.c
> @@ -1514,8 +1514,10 @@ dso__load_sym_internal(struct dso *dso, struct map
> *map, struct symsrc *syms_ss,
> }
>
> if (elf_section_by_name(runtime_ss->elf, _ss->ehdr, ,
> - ".text", NULL))
> + ".text", NULL)) {
> dso->text_offset = tshdr.sh_addr - tshdr.sh_offset;
> + dso->text_end = tshdr.sh_offset + tshdr.sh_size;
> + }
>
> if (runtime_ss->opdsec)
> opddata = elf_rawdata(runtime_ss->opdsec, NULL);
> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> index 3f36675b7c8f..f25e4e62cf25 100644
> --- a/tools/perf/util/symbol.c
> +++ b/tools/perf/util/symbol.c
> @@ -1733,8 +1733,10 @@ int dso__load_bfd_symbols(struct dso *dso, const char
> *debugfile)
> /* PE symbols can only have 4 bytes, so use .text high
> bits */
> dso->text_offset = section->vma - (u32)section->vma;
> dso->text_offset += (u32)bfd_asymbol_value(symbols[i]);
> + dso->text_end = (section->vma - dso->text_offset) +
> section->size;
> } else {
> dso->text_offset = section->vma - section->filepos;
> + dso->text_end = section->filepos + section->size;
> }
> }
>
Re: [PATCH 0/3] Fix for shellcheck issues with version "0.6"
On 9/7/23 22:45, Athira Rajeev wrote: > From: root > > shellcheck was run on perf tool shell scripts s a pre-requisite > to include a build option for shellcheck discussed here: > https://www.spinics.net/lists/linux-perf-users/msg25553.html > > And fixes were added for the coding/formatting issues in > two patchsets: > https://lore.kernel.org/linux-perf-users/20230613164145.50488-1-atraj...@linux.vnet.ibm.com/ > https://lore.kernel.org/linux-perf-users/20230709182800.53002-1-atraj...@linux.vnet.ibm.com/ > > Three additional issues are observed with shellcheck "0.6" and > this patchset covers those. With this patchset, > > # for F in $(find tests/shell/ -perm -o=x -name '*.sh'); do shellcheck -S > warning $F; done > # echo $? > 0 > Patchset looks good to me. Reviewed-by: Kajol Jain Thanks, Kajol Jain > Athira Rajeev (3): > tests/shell: Fix shellcheck SC1090 to handle the location of sourced > files > tests/shell: Fix shellcheck issues in tests/shell/stat+shadow_stat.sh > tetscase > tests/shell: Fix shellcheck warnings for SC2153 in multiple scripts > > tools/perf/tests/shell/coresight/asm_pure_loop.sh| 4 > tools/perf/tests/shell/coresight/memcpy_thread_16k_10.sh | 4 > tools/perf/tests/shell/coresight/thread_loop_check_tid_10.sh | 4 > tools/perf/tests/shell/coresight/thread_loop_check_tid_2.sh | 4 > tools/perf/tests/shell/coresight/unroll_loop_thread_10.sh| 4 > tools/perf/tests/shell/probe_vfs_getname.sh | 2 ++ > tools/perf/tests/shell/record+probe_libc_inet_pton.sh| 2 ++ > tools/perf/tests/shell/record+script_probe_vfs_getname.sh| 2 ++ > tools/perf/tests/shell/record.sh | 1 + > tools/perf/tests/shell/stat+csv_output.sh| 1 + > tools/perf/tests/shell/stat+csv_summary.sh | 4 ++-- > tools/perf/tests/shell/stat+shadow_stat.sh | 4 ++-- > tools/perf/tests/shell/stat+std_output.sh| 1 + > tools/perf/tests/shell/test_intel_pt.sh | 1 + > tools/perf/tests/shell/trace+probe_vfs_getname.sh| 1 + > 15 files changed, 35 insertions(+), 4 deletions(-) >
Re: [PATCH V2] perf test: Fix parse-events tests to skip parametrized events
On 9/7/23 22:29, Athira Rajeev wrote:
> Testcase "Parsing of all PMU events from sysfs" parse events for
> all PMUs, and not just cpu. In case of powerpc, the PowerVM
> environment supports events from hv_24x7 and hv_gpci PMU which
> is of example format like below:
>
> - hv_24x7/CPM_ADJUNCT_INST,domain=?,core=?/
> - hv_gpci/event,partition_id=?/
>
> The value for "?" needs to be filled in depending on system
> configuration. It is better to skip these parametrized events
> in this test as it is done in:
> 'commit b50d691e50e6 ("perf test: Fix "all PMU test" to skip
> parametrized events")' which handled a simialr instance with
> "all PMU test".
>
> Fix parse-events test to skip parametrized events since
> it needs proper setup of the parameters.
Patch looks good to me.
Reviewed-by: Kajol Jain
Thanks,
Kajol Jain
>
> Signed-off-by: Athira Rajeev
> ---
> Changelog:
> v1 -> v2:
> Addressed review comments from Ian. Updated size of
> pmu event name variable and changed bool name which is
> used to skip the test.
>
> tools/perf/tests/parse-events.c | 38 +
> 1 file changed, 38 insertions(+)
>
> diff --git a/tools/perf/tests/parse-events.c b/tools/perf/tests/parse-events.c
> index 658fb9599d95..1ecaeceb69f8 100644
> --- a/tools/perf/tests/parse-events.c
> +++ b/tools/perf/tests/parse-events.c
> @@ -2514,9 +2514,14 @@ static int test__pmu_events(struct test_suite *test
> __maybe_unused, int subtest
> while ((pmu = perf_pmus__scan(pmu)) != NULL) {
> struct stat st;
> char path[PATH_MAX];
> + char pmu_event[PATH_MAX];
> + char *buf = NULL;
> + FILE *file;
> struct dirent *ent;
> + size_t len = 0;
> DIR *dir;
> int err;
> + int n;
>
> snprintf(path, PATH_MAX,
> "%s/bus/event_source/devices/%s/events/",
> sysfs__mountpoint(), pmu->name);
> @@ -2538,11 +2543,44 @@ static int test__pmu_events(struct test_suite *test
> __maybe_unused, int subtest
> struct evlist_test e = { .name = NULL, };
> char name[2 * NAME_MAX + 1 + 12 + 3];
> int test_ret;
> + bool is_event_parameterized = 0;
>
> /* Names containing . are special and cannot be used
> directly */
> if (strchr(ent->d_name, '.'))
> continue;
>
> + /* exclude parametrized ones (name contains '?') */
> + n = snprintf(pmu_event, sizeof(pmu_event), "%s%s",
> path, ent->d_name);
> + if (n >= PATH_MAX) {
> + pr_err("pmu event name crossed PATH_MAX(%d)
> size\n", PATH_MAX);
> + continue;
> + }
> +
> + file = fopen(pmu_event, "r");
> + if (!file) {
> + pr_debug("can't open pmu event file for
> '%s'\n", ent->d_name);
> + ret = combine_test_results(ret, TEST_FAIL);
> + continue;
> + }
> +
> + if (getline(, , file) < 0) {
> + pr_debug(" pmu event: %s is a null event\n",
> ent->d_name);
> + ret = combine_test_results(ret, TEST_FAIL);
> + continue;
> + }
> +
> + if (strchr(buf, '?'))
> + is_event_parameterized = 1;
> +
> + free(buf);
> + buf = NULL;
> + fclose(file);
> +
> + if (is_event_parameterized == 1) {
> + pr_debug("skipping parametrized PMU event: %s
> which contains ?\n", pmu_event);
> + continue;
> + }
> +
> snprintf(name, sizeof(name), "%s/event=%s/u",
> pmu->name, ent->d_name);
>
> e.name = name;
Re: [PATCH v2 1/3] perf vendor events: Update JSON/events for power10 platform
On 9/6/23 19:56, Arnaldo Carvalho de Melo wrote:
> Em Tue, Sep 05, 2023 at 05:10:37PM +0530, Kajol Jain escreveu:
>> Update JSON/Events list with data-source events for power10 platform.
>
> Thanks, applied the series.
>
> - Arnaldo
Hi Arnaldo,
Thanks for pulling the patchset.
Thanks,
Kajol Jain
>
>
>> Signed-off-by: Kajol Jain
>> ---
>> .../arch/powerpc/power10/datasource.json | 1282 +
>> .../arch/powerpc/power10/others.json | 10 -
>> .../arch/powerpc/power10/translation.json |5 -
>> 3 files changed, 1282 insertions(+), 15 deletions(-)
>> create mode 100644
>> tools/perf/pmu-events/arch/powerpc/power10/datasource.json
>>
>> ---
>> Changelog:
>> v1->v2
>> - Split first patch as its bounce from
>> linux-perf-us...@vger.kernel.org mailing list because of
>> 'Message too long (>10 chars)' error.
>> ---
>> diff --git a/tools/perf/pmu-events/arch/powerpc/power10/datasource.json
>> b/tools/perf/pmu-events/arch/powerpc/power10/datasource.json
>> new file mode 100644
>> index ..12cfb9785433
>> --- /dev/null
>> +++ b/tools/perf/pmu-events/arch/powerpc/power10/datasource.json
>> @@ -0,0 +1,1282 @@
>> +[
>> + {
>> +"EventCode": "0x200FE",
>> +"EventName": "PM_DATA_FROM_L2MISS",
>> +"BriefDescription": "The processor's L1 data cache was reloaded from a
>> source beyond the local core's L2 due to a demand miss."
>> + },
>> + {
>> +"EventCode": "0x300FE",
>> +"EventName": "PM_DATA_FROM_L3MISS",
>> +"BriefDescription": "The processor's L1 data cache was reloaded from
>> beyond the local core's L3 due to a demand miss."
>> + },
>> + {
>> +"EventCode": "0x400FE",
>> +"EventName": "PM_DATA_FROM_MEMORY",
>> +"BriefDescription": "The processor's data cache was reloaded from
>> local, remote, or distant memory due to a demand miss."
>> + },
>> + {
>> +"EventCode": "0x0003C040",
>> +"EventName": "PM_INST_FROM_L2",
>> +"BriefDescription": "The processor's instruction cache was reloaded
>> from the local core's L2 due to a demand miss."
>> + },
>> + {
>> +"EventCode": "0x00034000C040",
>> +"EventName": "PM_DATA_FROM_L2",
>> +"BriefDescription": "The processor's L1 data cache was reloaded from
>> the local core's L2 due to a demand miss."
>> + },
>> + {
>> +"EventCode": "0x00030010C040",
>> +"EventName": "PM_INST_FROM_L2_ALL",
>> +"BriefDescription": "The processor's instruction cache was reloaded
>> from the local core's L2 due to a demand miss or prefetch reload."
>> + },
>> + {
>> +"EventCode": "0x00034020C040",
>> +"EventName": "PM_DATA_FROM_L2_ALL",
>> +"BriefDescription": "The processor's L1 data cache was reloaded from
>> the local core's L2 due to a demand miss or prefetch reload."
>> + },
>> + {
>> +"EventCode": "0x003FC040",
>> +"EventName": "PM_INST_FROM_L1MISS",
>> +"BriefDescription": "The processor's instruction cache was reloaded
>> from a source beyond the local core's L1 due to a demand miss."
>> + },
>> + {
>> +"EventCode": "0x003F4000C040",
>> +"EventName": "PM_DATA_FROM_L1MISS",
>> +"BriefDescription": "The processor's L1 data cache was reloaded from a
>> source beyond the local core's L1 due to a demand miss."
>> + },
>> + {
>> +"EventCode": "0x003F0010C040",
>> +"EventName": "PM_INST_FROM_L1MISS_ALL",
>> +"BriefDescription": "The processor's instruction cache was reloaded
>> from a source beyond the local core's L1 due to a demand miss or prefetch
>> reload."
>> + },
>> + {
>> +"EventCode": "0x003F4020C040",
>> +"EventName": "PM_DATA_FROM_L1MISS_ALL",
>> +"BriefDescription": "The processor's L1 data cache was reloaded from a
>> source beyond the local core's L1 due to a demand miss or prefetch reload."
>> + },
>> + {
>> +"EventCode": "0x4000C040",
>> +"EventName": "PM_DATA_FROM_L2_NO_CONFLICT",
>> +"BriefDescription": "The processor's L1 data cache was reloaded without
>> dispatch conflicts with data NOT in the MEPF state from the local core's L2
>> due to a demand miss."
>> + },
>> + {
>> +"EventCode": "0x4020C040",
>> +"EventName": "PM_DATA_FROM_L2_NO_CONFLICT_ALL",
>> +"BriefDescription": "The processor's L1 data cache was reloaded without
>> dispatch conflicts with data NOT in the MEPF state from the local core's L2
>> due to a demand miss or prefetch reload."
>> + },
>> + {
>> +"EventCode": "0x00404000C040",
>> +"EventName": "PM_DATA_FROM_L2_MEPF",
>> +"BriefDescription": "The processor's L1 data cache was reloaded with
>> data in the MEPF state without dispatch conflicts from the local core's L2
>> due to a demand miss."
>> + },
>> + {
>> +"EventCode": "0x00404020C040",
>> +"EventName": "PM_DATA_FROM_L2_MEPF_ALL",
>> +"BriefDescription": "The processor's L1 data cache was reloaded with
>> data in the MEPF state without dispatch conflicts
Re: [PATCH v2 2/3] perf vendor events: Update JSON/events for power10 platform
On 9/6/23 19:55, Arnaldo Carvalho de Melo wrote:
> Em Tue, Sep 05, 2023 at 05:10:38PM +0530, Kajol Jain escreveu:
>> Update JSON/Events list with additional data-source events
>> for power10 platform.
>
> I changed the cset title to:
>
> "perf vendor events power10: Add extra data-source events"
>
> As it was exactly the same as the first, so when someone does a 'git log
> --oneline' it looks like a straight dup.
>
> Please try to provide descriptive subjects.
Hi Arnaldo,
Thanks for updating it, I will make sure to not have duplicate subject
from next time.
Thanks,
Kajol Jain
>
> - Arnaldo
>
>> Signed-off-by: Kajol Jain
>> ---
>> .../arch/powerpc/power10/datasource.json | 505 ++
>> 1 file changed, 505 insertions(+)
>>
>> diff --git a/tools/perf/pmu-events/arch/powerpc/power10/datasource.json
>> b/tools/perf/pmu-events/arch/powerpc/power10/datasource.json
>> index 12cfb9785433..6b0356f2d301 100644
>> --- a/tools/perf/pmu-events/arch/powerpc/power10/datasource.json
>> +++ b/tools/perf/pmu-events/arch/powerpc/power10/datasource.json
>> @@ -1278,5 +1278,510 @@
>> "EventCode": "0x0A424000C142",
>> "EventName": "PM_MRK_DATA_FROM_NON_REGENT_L2L3_MOD",
>> "BriefDescription": "The processor's L1 data cache was reloaded with a
>> line in the M (exclusive) state from another core's L2 or L3 on the same
>> chip in a different regent due to a demand miss for a marked instruction."
>> + },
>> + {
>> +"EventCode": "0x0A424020C142",
>> +"EventName": "PM_MRK_DATA_FROM_NON_REGENT_L2L3_MOD_ALL",
>> +"BriefDescription": "The processor's L1 data cache was reloaded with a
>> line in the M (exclusive) state from another core's L2 or L3 on the same
>> chip in a different regent due to a demand miss or prefetch reload for a
>> marked instruction."
>> + },
>> + {
>> +"EventCode": "0x0A03C142",
>> +"EventName": "PM_MRK_INST_FROM_NON_REGENT_L2L3",
>> +"BriefDescription": "The processor's instruction cache was reloaded
>> from another core's L2 or L3 on the same chip in a different regent due to a
>> demand miss for a marked instruction."
>> + },
>> + {
>> +"EventCode": "0x0A034000C142",
>> +"EventName": "PM_MRK_DATA_FROM_NON_REGENT_L2L3",
>> +"BriefDescription": "The processor's L1 data cache was reloaded from
>> another core's L2 or L3 on the same chip in a different regent due to a
>> demand miss for a marked instruction."
>> + },
>> + {
>> +"EventCode": "0x0A030010C142",
>> +"EventName": "PM_MRK_INST_FROM_NON_REGENT_L2L3_ALL",
>> +"BriefDescription": "The processor's instruction cache was reloaded
>> from another core's L2 or L3 on the same chip in a different regent due to a
>> demand miss or prefetch reload for a marked instruction."
>> + },
>> + {
>> +"EventCode": "0x0A034020C142",
>> +"EventName": "PM_MRK_DATA_FROM_NON_REGENT_L2L3_ALL",
>> +"BriefDescription": "The processor's L1 data cache was reloaded from
>> another core's L2 or L3 on the same chip in a different regent due to a
>> demand miss or prefetch reload for a marked instruction."
>> + },
>> + {
>> +"EventCode": "0x0941C142",
>> +"EventName": "PM_MRK_INST_FROM_LMEM",
>> +"BriefDescription": "The processor's instruction cache was reloaded
>> from the local chip's memory due to a demand miss for a marked instruction."
>> + },
>> + {
>> +"EventCode": "0x09404000C142",
>> +"EventName": "PM_MRK_DATA_FROM_LMEM",
>> +"BriefDescription": "The processor's L1 data cache was reloaded from
>> the local chip's memory due to a demand miss for a marked instruction."
>> + },
>> + {
>> +"EventCode": "0x09410010C142",
>> +"EventName": "PM_MRK_INST_FROM_LMEM_ALL",
>> +"BriefDescription": "The processor's instruction cache was reloaded
>> from the local chip's memory due to a demand miss or prefetch reload for a
>> marked instruction."
>> + },
>> + {
>> +"EventCode": "0x09404020C142",
>> +"EventName": "PM_MRK_DATA_FROM_LMEM_ALL",
>> +"BriefDescription": "The processor's L1 data cache was reloaded from
>> the local chip's memory due to a demand miss or prefetch reload for a marked
>> instruction."
>> + },
>> + {
>> +"EventCode": "0x09804000C142",
>> +"EventName": "PM_MRK_DATA_FROM_L_OC_CACHE",
>> +"BriefDescription": "The processor's L1 data cache was reloaded from
>> the local chip's OpenCAPI cache due to a demand miss for a marked
>> instruction."
>> + },
>> + {
>> +"EventCode": "0x09804020C142",
>> +"EventName": "PM_MRK_DATA_FROM_L_OC_CACHE_ALL",
>> +"BriefDescription": "The processor's L1 data cache was reloaded from
>> the local chip's OpenCAPI cache due to a demand miss or prefetch reload for
>> a marked instruction."
>> + },
>> + {
>> +"EventCode": "0x09C04000C142",
>> +"EventName": "PM_MRK_DATA_FROM_L_OC_MEM",
>> +"BriefDescription": "The processor's L1 data cache was reloaded
Re: [PATCH v2 1/3] perf vendor events: Update JSON/events for power10 platform
On 9/6/23 19:52, Arnaldo Carvalho de Melo wrote:
> Em Tue, Sep 05, 2023 at 05:10:37PM +0530, Kajol Jain escreveu:
>> Update JSON/Events list with data-source events for power10 platform.
>
> Next time could you please provide some pointer to the document from
> where these metrics came if it is available online?
>
Hi Arnaldo,
Sure I will take care of it next time.
Thanks,
Kajol Jain
> - Arnaldo
>
>> Signed-off-by: Kajol Jain
>> ---
>> .../arch/powerpc/power10/datasource.json | 1282 +
>> .../arch/powerpc/power10/others.json | 10 -
>> .../arch/powerpc/power10/translation.json |5 -
>> 3 files changed, 1282 insertions(+), 15 deletions(-)
>> create mode 100644
>> tools/perf/pmu-events/arch/powerpc/power10/datasource.json
>>
>> ---
>> Changelog:
>> v1->v2
>> - Split first patch as its bounce from
>> linux-perf-us...@vger.kernel.org mailing list because of
>> 'Message too long (>10 chars)' error.
>> ---
>> diff --git a/tools/perf/pmu-events/arch/powerpc/power10/datasource.json
>> b/tools/perf/pmu-events/arch/powerpc/power10/datasource.json
>> new file mode 100644
>> index ..12cfb9785433
>> --- /dev/null
>> +++ b/tools/perf/pmu-events/arch/powerpc/power10/datasource.json
>> @@ -0,0 +1,1282 @@
>> +[
>> + {
>> +"EventCode": "0x200FE",
>> +"EventName": "PM_DATA_FROM_L2MISS",
>> +"BriefDescription": "The processor's L1 data cache was reloaded from a
>> source beyond the local core's L2 due to a demand miss."
>> + },
>> + {
>> +"EventCode": "0x300FE",
>> +"EventName": "PM_DATA_FROM_L3MISS",
>> +"BriefDescription": "The processor's L1 data cache was reloaded from
>> beyond the local core's L3 due to a demand miss."
>> + },
>> + {
>> +"EventCode": "0x400FE",
>> +"EventName": "PM_DATA_FROM_MEMORY",
>> +"BriefDescription": "The processor's data cache was reloaded from
>> local, remote, or distant memory due to a demand miss."
>> + },
>> + {
>> +"EventCode": "0x0003C040",
>> +"EventName": "PM_INST_FROM_L2",
>> +"BriefDescription": "The processor's instruction cache was reloaded
>> from the local core's L2 due to a demand miss."
>> + },
>> + {
>> +"EventCode": "0x00034000C040",
>> +"EventName": "PM_DATA_FROM_L2",
>> +"BriefDescription": "The processor's L1 data cache was reloaded from
>> the local core's L2 due to a demand miss."
>> + },
>> + {
>> +"EventCode": "0x00030010C040",
>> +"EventName": "PM_INST_FROM_L2_ALL",
>> +"BriefDescription": "The processor's instruction cache was reloaded
>> from the local core's L2 due to a demand miss or prefetch reload."
>> + },
>> + {
>> +"EventCode": "0x00034020C040",
>> +"EventName": "PM_DATA_FROM_L2_ALL",
>> +"BriefDescription": "The processor's L1 data cache was reloaded from
>> the local core's L2 due to a demand miss or prefetch reload."
>> + },
>> + {
>> +"EventCode": "0x003FC040",
>> +"EventName": "PM_INST_FROM_L1MISS",
>> +"BriefDescription": "The processor's instruction cache was reloaded
>> from a source beyond the local core's L1 due to a demand miss."
>> + },
>> + {
>> +"EventCode": "0x003F4000C040",
>> +"EventName": "PM_DATA_FROM_L1MISS",
>> +"BriefDescription": "The processor's L1 data cache was reloaded from a
>> source beyond the local core's L1 due to a demand miss."
>> + },
>> + {
>> +"EventCode": "0x003F0010C040",
>> +"EventName": "PM_INST_FROM_L1MISS_ALL",
>> +"BriefDescription": "The processor's instruction cache was reloaded
>> from a source beyond the local core's L1 due to a demand miss or prefetch
>> reload."
>> + },
>> + {
>> +"EventCode": "0x003F4020C040",
>> +"EventName": "PM_DATA_FROM_L1MISS_ALL",
>> +"BriefDescription": "The processor's L1 data cache was reloaded from a
>> source beyond the local core's L1 due to a demand miss or prefetch reload."
>> + },
>> + {
>> +"EventCode": "0x4000C040",
>> +"EventName": "PM_DATA_FROM_L2_NO_CONFLICT",
>> +"BriefDescription": "The processor's L1 data cache was reloaded without
>> dispatch conflicts with data NOT in the MEPF state from the local core's L2
>> due to a demand miss."
>> + },
>> + {
>> +"EventCode": "0x4020C040",
>> +"EventName": "PM_DATA_FROM_L2_NO_CONFLICT_ALL",
>> +"BriefDescription": "The processor's L1 data cache was reloaded without
>> dispatch conflicts with data NOT in the MEPF state from the local core's L2
>> due to a demand miss or prefetch reload."
>> + },
>> + {
>> +"EventCode": "0x00404000C040",
>> +"EventName": "PM_DATA_FROM_L2_MEPF",
>> +"BriefDescription": "The processor's L1 data cache was reloaded with
>> data in the MEPF state without dispatch conflicts from the local core's L2
>> due to a demand miss."
>> + },
>> + {
>> +"EventCode": "0x00404020C040",
>> +"EventName": "PM_DATA_FROM_L2_MEPF_ALL",
>> +"BriefDescription":
Re: [PATCH 1/2] perf vendor events: Update JSON/events for power10 platform
Hi Arnaldo,
Can you please pull this patchset which is adding more json events
for power10 platform.
Thanks,
Kajol Jain
On 8/23/23 13:25, Kajol Jain wrote:
> Update JSON/Events list with data-source events for power10 platform.
>
> Signed-off-by: Kajol Jain
> ---
> .../arch/powerpc/power10/datasource.json | 1787 +
> .../arch/powerpc/power10/others.json | 10 -
> .../arch/powerpc/power10/translation.json |5 -
> 3 files changed, 1787 insertions(+), 15 deletions(-)
> create mode 100644 tools/perf/pmu-events/arch/powerpc/power10/datasource.json
>
> diff --git a/tools/perf/pmu-events/arch/powerpc/power10/datasource.json
> b/tools/perf/pmu-events/arch/powerpc/power10/datasource.json
> new file mode 100644
> index ..6b0356f2d301
> --- /dev/null
> +++ b/tools/perf/pmu-events/arch/powerpc/power10/datasource.json
> @@ -0,0 +1,1787 @@
> +[
> + {
> +"EventCode": "0x200FE",
> +"EventName": "PM_DATA_FROM_L2MISS",
> +"BriefDescription": "The processor's L1 data cache was reloaded from a
> source beyond the local core's L2 due to a demand miss."
> + },
> + {
> +"EventCode": "0x300FE",
> +"EventName": "PM_DATA_FROM_L3MISS",
> +"BriefDescription": "The processor's L1 data cache was reloaded from
> beyond the local core's L3 due to a demand miss."
> + },
> + {
> +"EventCode": "0x400FE",
> +"EventName": "PM_DATA_FROM_MEMORY",
> +"BriefDescription": "The processor's data cache was reloaded from local,
> remote, or distant memory due to a demand miss."
> + },
> + {
> +"EventCode": "0x0003C040",
> +"EventName": "PM_INST_FROM_L2",
> +"BriefDescription": "The processor's instruction cache was reloaded from
> the local core's L2 due to a demand miss."
> + },
> + {
> +"EventCode": "0x00034000C040",
> +"EventName": "PM_DATA_FROM_L2",
> +"BriefDescription": "The processor's L1 data cache was reloaded from the
> local core's L2 due to a demand miss."
> + },
> + {
> +"EventCode": "0x00030010C040",
> +"EventName": "PM_INST_FROM_L2_ALL",
> +"BriefDescription": "The processor's instruction cache was reloaded from
> the local core's L2 due to a demand miss or prefetch reload."
> + },
> + {
> +"EventCode": "0x00034020C040",
> +"EventName": "PM_DATA_FROM_L2_ALL",
> +"BriefDescription": "The processor's L1 data cache was reloaded from the
> local core's L2 due to a demand miss or prefetch reload."
> + },
> + {
> +"EventCode": "0x003FC040",
> +"EventName": "PM_INST_FROM_L1MISS",
> +"BriefDescription": "The processor's instruction cache was reloaded from
> a source beyond the local core's L1 due to a demand miss."
> + },
> + {
> +"EventCode": "0x003F4000C040",
> +"EventName": "PM_DATA_FROM_L1MISS",
> +"BriefDescription": "The processor's L1 data cache was reloaded from a
> source beyond the local core's L1 due to a demand miss."
> + },
> + {
> +"EventCode": "0x003F0010C040",
> +"EventName": "PM_INST_FROM_L1MISS_ALL",
> +"BriefDescription": "The processor's instruction cache was reloaded from
> a source beyond the local core's L1 due to a demand miss or prefetch reload."
> + },
> + {
> +"EventCode": "0x003F4020C040",
> +"EventName": "PM_DATA_FROM_L1MISS_ALL",
> +"BriefDescription": "The processor's L1 data cache was reloaded from a
> source beyond the local core's L1 due to a demand miss or prefetch reload."
> + },
> + {
> +"EventCode": "0x4000C040",
> +"EventName": "PM_DATA_FROM_L2_NO_CONFLICT",
> +"BriefDescription": "The processor's L1 data cache was reloaded without
> dispatch conflicts with data NOT in the MEPF state from the local core's L2
> due to a demand miss."
> + },
> + {
> +"EventCode": "0x4020C040",
> +"EventName": "PM_DATA_FROM_L2_NO_CONFLICT_ALL",
> +"BriefDescription": "The processor's L1 data cache was reloaded without
> dispatch conflicts with data NOT in the MEPF state from the local core's L2
> due to a demand miss or prefetch reload."
> + },
> + {
> +"EventCode": "0x00404000C040",
> +"EventName": "PM_DATA_FROM_L2_MEPF",
> +"BriefDescription": "The processor's L1 data cache was reloaded with
> data in the MEPF state without dispatch conflicts from the local core's L2
> due to a demand miss."
> + },
> + {
> +"EventCode": "0x00404020C040",
> +"EventName": "PM_DATA_FROM_L2_MEPF_ALL",
> +"BriefDescription": "The processor's L1 data cache was reloaded with
> data in the MEPF state without dispatch conflicts from the local core's L2
> due to a demand miss or prefetch reload."
> + },
> + {
> +"EventCode": "0x00804000C040",
> +"EventName": "PM_DATA_FROM_L2_LDHITST_CONFLICT",
> +"BriefDescription": "The processor's L1 data cache was reloaded with
> data that had a dispatch conflict on ld-hit-store from the local core's L2
> due to a demand miss."
> + },
> + {
>
Re: [PATCH V2 00/26] tools/perf: Fix shellcheck coding/formatting issues of perf tool shell scripts
On 7/20/23 10:42, Athira Rajeev wrote: > > >> On 19-Jul-2023, at 11:16 PM, Ian Rogers wrote: >> >> On Tue, Jul 18, 2023 at 11:17 PM kajoljain wrote: >>> >>> Hi, >>> >>> Looking for review comments on this patchset. >>> >>> Thanks, >>> Kajol Jain >>> >>> >>> On 7/9/23 23:57, Athira Rajeev wrote: >>>> Patchset covers a set of fixes for coding/formatting issues observed while >>>> running shellcheck tool on the perf shell scripts. >>>> >>>> This cleanup is a pre-requisite to include a build option for shellcheck >>>> discussed here: >>>> https://www.spinics.net/lists/linux-perf-users/msg25553.html >>>> First set of patches were posted here: >>>> https://lore.kernel.org/linux-perf-users/53b7d823-1570-4289-a632-2205ee2b5...@linux.vnet.ibm.com/T/#t >>>> >>>> This patchset covers remaining set of shell scripts which needs >>>> fix. Patch 1 is resubmission of patch 6 from the initial series. >>>> Patch 15, 16 and 22 touches code from tools/perf/trace/beauty. >>>> Other patches are fixes for scripts from tools/perf/tests. >>>> >>>> The shellcheck is run for severity level for errors and warnings. >>>> Command used: >>>> >>>> # for F in $(find tests/shell/ -perm -o=x -name '*.sh'); do shellcheck -S >>>> warning $F; done >>>> # echo $? >>>> 0 >>>> >> >> I don't see anything objectionable in the changes so for the series: >> Acked-by: Ian Rogers >> >> Some thoughts: >> - Adding "#!/bin/bash" to scripts in tools/perf/tests/lib - I think >> we didn't do this to avoid these being included as tests. There are >> now extra checks when finding shell tests, so I can imagine doing this >> isn't a regression but just a heads up. >> - I think James' comment was addressed: >> https://lore.kernel.org/linux-perf-users/334989bf-5501-494c-f246-81878fd2f...@arm.com/ >> - Why aren't these changes being mailed to LKML? The wider community >> on LKML have thoughts on shell scripts, plus it makes the changes miss >> my mail filters. >> - Can we automate this testing into the build? For example, following >> a similar kernel build pattern we run a python test and make the log >> output a requirement here: >> https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/pmu-events/Build?h=perf-tools-next#n30 >> I think we can translate: >> for F in $(find tests/shell/ -perm -o=x -name '*.sh'); do shellcheck >> -S warning $F; done >> into a rule in make for log files that are then a dependency on the >> perf binary. We can then parallel shellcheck during the build and >> avoid regressions. We probably need a CONFIG_SHELLCHECK feature check >> in the build to avoid not having shellcheck breaking the build. > > Hi Ian > > Thanks for the comments. > Yes, next step after this is to include build option for shellcheck by > updating Makefile. > We will surely get into that build option enablement patch once we have all > these corrections in place. > > Thanks > Athira >> Hi Ian, Thanks for reviewing the patches. As athira mentioned our next is to include build option. So, we will work on it next once all the correction done. Thanks, Kajol Jain >> Thanks, >> Ian >> >>>> Changelog: >>>> v1 -> v2: >>>> - Rebased on top of perf-tools-next from: >>>> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/log/?h=perf-tools-next >>>> >>>> - Fixed shellcheck errors and warnings reported for newly >>>>added changes from perf-tools-next branch >>>> >>>> - Addressed review comment from James clark for patch >>>>number 13 from V1. The changes in patch 13 were not necessary >>>>since the file "tests/shell/lib/coresight.sh" is sourced from >>>>other test files. >>>> >>>> Akanksha J N (1): >>>> tools/perf/tests: Fix shellcheck warnings for >>>>trace+probe_vfs_getname.sh >>>> >>>> Athira Rajeev (14): >>>> tools/perf/tests: fix test_arm_spe_fork.sh signal case issues >>>> tools/perf/tests: Fix unused variable references in >>>>stat+csv_summary.sh testcase >>>> tools/perf/tests: fix shellcheck warning for >>>>test_perf_data_converter_json.sh testcase >>>> tools/perf/
Re: [PATCH V2 00/26] tools/perf: Fix shellcheck coding/formatting issues of perf tool shell scripts
Hi, Looking for review comments on this patchset. Thanks, Kajol Jain On 7/9/23 23:57, Athira Rajeev wrote: > Patchset covers a set of fixes for coding/formatting issues observed while > running shellcheck tool on the perf shell scripts. > > This cleanup is a pre-requisite to include a build option for shellcheck > discussed here: https://www.spinics.net/lists/linux-perf-users/msg25553.html > First set of patches were posted here: > https://lore.kernel.org/linux-perf-users/53b7d823-1570-4289-a632-2205ee2b5...@linux.vnet.ibm.com/T/#t > > This patchset covers remaining set of shell scripts which needs > fix. Patch 1 is resubmission of patch 6 from the initial series. > Patch 15, 16 and 22 touches code from tools/perf/trace/beauty. > Other patches are fixes for scripts from tools/perf/tests. > > The shellcheck is run for severity level for errors and warnings. > Command used: > > # for F in $(find tests/shell/ -perm -o=x -name '*.sh'); do shellcheck -S > warning $F; done > # echo $? > 0 > > Changelog: > v1 -> v2: > - Rebased on top of perf-tools-next from: > > https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/log/?h=perf-tools-next > > - Fixed shellcheck errors and warnings reported for newly > added changes from perf-tools-next branch > > - Addressed review comment from James clark for patch > number 13 from V1. The changes in patch 13 were not necessary > since the file "tests/shell/lib/coresight.sh" is sourced from > other test files. > > Akanksha J N (1): > tools/perf/tests: Fix shellcheck warnings for > trace+probe_vfs_getname.sh > > Athira Rajeev (14): > tools/perf/tests: fix test_arm_spe_fork.sh signal case issues > tools/perf/tests: Fix unused variable references in > stat+csv_summary.sh testcase > tools/perf/tests: fix shellcheck warning for > test_perf_data_converter_json.sh testcase > tools/perf/tests: Fix shellcheck issue for stat_bpf_counters.sh > testcase > tools/perf/tests: Fix shellcheck issues in > tests/shell/stat+shadow_stat.sh tetscase > tools/perf/tests: Fix shellcheck warnings for > thread_loop_check_tid_10.sh > tools/perf/tests: Fix shellcheck warnings for unroll_loop_thread_10.sh > tools/perf/tests: Fix shellcheck warnings for lib/probe_vfs_getname.sh > tools/perf/tests: Fix the shellcheck warnings in lib/waiting.sh > tools/perf/trace: Fix x86_arch_prctl.sh to address shellcheck warnings > tools/perf/arch/x86: Fix syscalltbl.sh to address shellcheck warnings > tools/perf/tests/shell: Fix the shellcheck warnings in > record+zstd_comp_decomp.sh > tools/perf/tests/shell: Fix shellcheck warning for stat+std_output.sh > testcase > tools/perf/tests: Fix shellcheck warning for stat+std_output.sh > testcase > > Kajol Jain (11): > tools/perf/tests: Fix shellcheck warning for probe_vfs_getname.sh > testcase > tools/perf/tests: Fix shellcheck warning for record_offcpu.sh testcase > tools/perf/tests: Fix shellcheck issue for lock_contention.sh testcase > tools/perf/tests: Fix shellcheck issue for stat_bpf_counters_cgrp.sh > testcase > tools/perf/tests: Fix shellcheck warning for asm_pure_loop.sh shell > script > tools/perf/tests: Fix shellcheck warning for memcpy_thread_16k_10.sh > shell script > tools/perf/tests: Fix shellcheck warning for probe.sh shell script > tools/perf/trace: Fix shellcheck issue for arch_errno_names.sh script > tools/perf: Fix shellcheck issue for check-headers.sh script > tools/shell/coresight: Fix shellcheck warning for > thread_loop_check_tid_2.sh shell script > tools/perf/tests/shell/lib: Fix shellcheck warning for stat_output.sh > shell script > > .../arch/x86/entry/syscalls/syscalltbl.sh | 2 +- > tools/perf/check-headers.sh | 6 ++-- > .../tests/shell/coresight/asm_pure_loop.sh| 2 +- > .../shell/coresight/memcpy_thread_16k_10.sh | 2 +- > .../coresight/thread_loop_check_tid_10.sh | 2 +- > .../coresight/thread_loop_check_tid_2.sh | 2 +- > .../shell/coresight/unroll_loop_thread_10.sh | 2 +- > tools/perf/tests/shell/lib/probe.sh | 1 + > .../perf/tests/shell/lib/probe_vfs_getname.sh | 5 ++-- > tools/perf/tests/shell/lib/stat_output.sh | 1 + > tools/perf/tests/shell/lib/waiting.sh | 1 + > tools/perf/tests/shell/lock_contention.sh | 12 > tools/perf/tests/shell/probe_vfs_getname.sh | 4 +-- > .../tests/shell/record+zstd_comp_decomp.sh| 14 +- > tools/perf/tests/shell/record_offcpu.sh | 6 ++-- > tools/perf/tests/shell/stat+csv_output.sh | 2 +- > tools/perf/tests/shell/stat+csv_summary.sh| 4 +-- > tools/perf/tests/shell/stat+shadow_stat.sh| 4 +-- > tools/perf/tests/shell/stat+std_output.sh | 3 +- > tools/perf/tests/shell/stat_bpf_counters.sh | 4 +-- > .../tests/shell/stat_bpf_counters_cgrp.sh | 28 --- > tools/perf/tests/shell/test_arm_spe_fork.sh
Re: [PATCH v2 02/10] docs: ABI: sysfs-bus-event_source-devices-hv_gpci: Document processor_bus_topology sysfs interface file
Thanks Randy for the review comments, I will do these updates for all documentation patches in my next version of patchset. Thanks, Kajol Jain On 7/12/23 02:22, Randy Dunlap wrote: > Hi-- > > On 7/10/23 02:27, Kajol Jain wrote: >> Add details of the new hv-gpci interface file called >> "processor_bus_topology" in the ABI documentation. >> >> Signed-off-by: Kajol Jain >> --- >> .../sysfs-bus-event_source-devices-hv_gpci| 32 +++ >> 1 file changed, 32 insertions(+) >> >> diff --git >> a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci >> b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci >> index 12e2bf92783f..2eeeab9a20fa 100644 >> --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci >> +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci >> @@ -80,3 +80,35 @@ Contact: Linux on PowerPC Developer List >> >> Description:read only >> This sysfs file exposes the cpumask which is designated to make >> HCALLs to retrieve hv-gpci pmu event counter data. >> + >> +What: /sys/devices/hv_gpci/interface/processor_bus_topology >> +Date: July 2023 >> +Contact:Linux on PowerPC Developer List >> +Description:admin read only >> +This sysfs file exposes the system topology information by >> making HCALL >> +H_GET_PERF_COUNTER_INFO. The HCALL is made with counter request >> value >> +PROCESSOR_BUS_TOPOLOGY(0xD0). >> + >> +* This sysfs file will be created only for power10 and above >> platforms. >> + >> +* User needs root privileges to read data from this sysfs file. >> + >> +* This sysfs file will be created, only when the HCALL returns >> "H_SUCESS", > > > H_SUCCESS > >> + "H_AUTHORITY" and "H_PARAMETER" as the return type. > > s/and/or/ > >> + >> + HCALL with return error type "H_AUTHORITY", can be resolved >> during > >Drop the comma ^ > >> + runtime by setting "Enable Performance Information >> Collection" option. >> + >> +* The end user reading this sysfs file must decode the content >> as per >> + underlying platform/firmware. >> + >> +Possible error codes while reading this sysfs file: >> + >> +* "-EPERM" : Partition is not permitted to retrieve performance >> information, >> +required to set "Enable Performance Information >> Collection" option. >> + >> +* "-EIO" : Can't retrieve system information because of invalid >> buffer length/invalid address >> + or because of some hardware error. Refer >> getPerfCountInfo documentation for > > Refer to > >> + more information. >> + >> +* "-EFBIG" : System information exceeds PAGE_SIZE. >
Re: [PATCH] perf vendor events power9: Remove UTF-8 characters from json files
On 3/29/23 18:54, Arnaldo Carvalho de Melo wrote:
> Em Tue, Mar 28, 2023 at 09:21:49AM -0700, Ian Rogers escreveu:
>> On Tue, Mar 28, 2023 at 4:30 AM Kajol Jain wrote:
>>>
>>> Commit 3c22ba524304 ("perf vendor events powerpc: Update POWER9 events")
>>> added and updated power9 pmu json events. However some of the json
>>> events which are part of other.json and pipeline.json files,
>>> contains UTF-8 characters in their brief description.
>>> Having UTF-8 character could brakes the perf build on some distros.
>>
>> nit: s/bakes/break/
>
> I'll fix that later, thans.
>
>>> Fix this issue by removing the UTF-8 characters from other.json and
>>> pipeline.json files.
>>>
>>> Result without the fix patch:
>
> [perfbuilder@five ~]$ cat dm.log/summary
>123.25 ubuntu:18.04-x-powerpc: Ok powerpc-linux-gnu-gcc
> (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
>224.56 ubuntu:18.04-x-powerpc64 : Ok powerpc64-linux-gnu-gcc
> (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
>325.06 ubuntu:18.04-x-powerpc64el: Ok powerpc64le-linux-gnu-gcc
> (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
> BUILD_TARBALL_HEAD=9da5ab1d38cd17fb47cbe5a1f95bca63e6ca9796
>
Thanks Ian and Arnaldo for reviewing it.
Thanks,
Kajol Jain
>>> [command]# file -i pmu-events/arch/powerpc/power9/*
>>> pmu-events/arch/powerpc/power9/cache.json: application/json;
>>> charset=us-ascii
>>> pmu-events/arch/powerpc/power9/floating-point.json: application/json;
>>> charset=us-ascii
>>> pmu-events/arch/powerpc/power9/frontend.json: application/json;
>>> charset=us-ascii
>>> pmu-events/arch/powerpc/power9/marked.json: application/json;
>>> charset=us-ascii
>>> pmu-events/arch/powerpc/power9/memory.json: application/json;
>>> charset=us-ascii
>>> pmu-events/arch/powerpc/power9/metrics.json:application/json;
>>> charset=us-ascii
>>> pmu-events/arch/powerpc/power9/nest_metrics.json: application/json;
>>> charset=us-ascii
>>> pmu-events/arch/powerpc/power9/other.json: application/json;
>>> charset=utf-8
>>> pmu-events/arch/powerpc/power9/pipeline.json: application/json;
>>> charset=utf-8
>>> pmu-events/arch/powerpc/power9/pmc.json:application/json;
>>> charset=us-ascii
>>> pmu-events/arch/powerpc/power9/translation.json:application/json;
>>> charset=us-ascii
>>>
>>> Result with the fix patch:
>>>
>>> [command]# file -i pmu-events/arch/powerpc/power9/*
>>> pmu-events/arch/powerpc/power9/cache.json: application/json;
>>> charset=us-ascii
>>> pmu-events/arch/powerpc/power9/floating-point.json: application/json;
>>> charset=us-ascii
>>> pmu-events/arch/powerpc/power9/frontend.json: application/json;
>>> charset=us-ascii
>>> pmu-events/arch/powerpc/power9/marked.json: application/json;
>>> charset=us-ascii
>>> pmu-events/arch/powerpc/power9/memory.json: application/json;
>>> charset=us-ascii
>>> pmu-events/arch/powerpc/power9/metrics.json:application/json;
>>> charset=us-ascii
>>> pmu-events/arch/powerpc/power9/nest_metrics.json: application/json;
>>> charset=us-ascii
>>> pmu-events/arch/powerpc/power9/other.json: application/json;
>>> charset=us-ascii
>>> pmu-events/arch/powerpc/power9/pipeline.json: application/json;
>>> charset=us-ascii
>>> pmu-events/arch/powerpc/power9/pmc.json:application/json;
>>> charset=us-ascii
>>> pmu-events/arch/powerpc/power9/translation.json:application/json;
>>> charset=us-ascii
>>>
>>> Fixes: 3c22ba524304 ("perf vendor events powerpc: Update POWER9 events")
>>> Reported-by: Arnaldo Carvalho de Melo
>>> Link: https://lore.kernel.org/lkml/zbxp77deq7ikt...@kernel.org/
>>> Signed-off-by: Kajol Jain
>>
>> Acked-by: Ian Rogers
>>
>> Thanks,
>> Ian
>>
>>> ---
>>> tools/perf/pmu-events/arch/powerpc/power9/other.json| 4 ++--
>>> tools/perf/pmu-events/arch/powerpc/power9/pipeline.json | 2 +-
>>> 2 files changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/tools/perf/pmu-events/arch/powerpc/power9/other.json
>>> b/tools/perf/pmu-events/arch/powerpc/power9/other.json
>>> index 3f69422c21f9..f10bd554521a 100644
>>> --- a/tools/perf/pmu-events/arch/powerpc/power9/other.json
>>> +++ b/tools/perf/pmu-events/arch/powerpc/power9/other.json
>>> @@ -1417,7 +1417,7 @@
>>>{
>>> "EventCode": "0x45054",
>>> "EventName": "PM_FMA_CMPL",
>>> -"BriefDescription": "two flops operation completed (fmadd, fnmadd,
>>> fmsub, fnmsub) Scalar instructions only. "
>>> +"BriefDescription": "two flops operation completed (fmadd, fnmadd,
>>> fmsub, fnmsub) Scalar instructions only."
>>>},
>>>{
>>> "EventCode": "0x201E8",
>>> @@ -2017,7 +2017,7 @@
>>>{
>>> "EventCode": "0xC0BC",
>>> "EventName": "PM_LSU_FLUSH_OTHER",
>>> -"BriefDescription": "Other LSU flushes including: Sync (sync ack from
>>> L2 caused search of LRQ for oldest snooped load, This will either signal a
>>> Precise Flush of the oldest snooped loa
Re: perf tools power9 JSON files build breakage on ubuntu 18.04 cross build
On 3/23/23 18:41, Arnaldo Carvalho de Melo wrote: > Exception processing pmu-events/arch/powerpc/power9/other.json > Traceback (most recent call last): > File "pmu-events/jevents.py", line 997, in > main() > File "pmu-events/jevents.py", line 979, in main > ftw(arch_path, [], preprocess_one_file) > File "pmu-events/jevents.py", line 935, in ftw > ftw(item.path, parents + [item.name], action) > File "pmu-events/jevents.py", line 933, in ftw > action(parents, item) > File "pmu-events/jevents.py", line 514, in preprocess_one_file > for event in read_json_events(item.path, topic): > File "pmu-events/jevents.py", line 388, in read_json_events > events = json.load(open(path), object_hook=JsonEvent) > File "/usr/lib/python3.6/json/__init__.py", line 296, in load > return loads(fp.read(), > File "/usr/lib/python3.6/encodings/ascii.py", line 26, in decode > return codecs.ascii_decode(input, self.errors)[0] > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 55090: > ordinal not in range(128) > CC /tmp/build/perf/tests/expr.o > pmu-events/Build:35: recipe for target > '/tmp/build/perf/pmu-events/pmu-events.c' failed > make[3]: *** [/tmp/build/perf/pmu-events/pmu-events.c] Error 1 > make[3]: *** Deleting file '/tmp/build/perf/pmu-events/pmu-events.c' > Makefile.perf:679: recipe for target > '/tmp/build/perf/pmu-events/pmu-events-in.o' failed > make[2]: *** [/tmp/build/perf/pmu-events/pmu-events-in.o] Error 2 > make[2]: *** Waiting for unfinished jobs > > > Now jevents is an opt-out feature so I'm noticing these problems. Hi Arnaldo, Thanks for raising it. I will check this issue. Thanks, Kajol Jain > > A similar fix for s390 was accepted today: > > > https://lore.kernel.org/r/20230323122532.2305847-1-tmri...@linux.ibm.com > https://lore.kernel.org/r/ZBwkl77/I31AQk12@osiris
Re: Possible bug in linux-6.2/tools/testing/selftests/powerpc/pmu/sampling_tests/mmcra_thresh_marked_sample_test.c
On 2/27/23 10:56, Michael Ellerman wrote: > David Binderman writes: >> Hello there, >> >> I ran the static analyser cppcheck over the linux-6.2 source code and got >> this: >> >> linux-6.2/tools/testing/selftests/powerpc/pmu/sampling_tests/mmcra_thresh_marked_sample_test.c:68:10: >> style: Same expression '0x3' found multiple times in chain of '&' >> operators. [duplicateExpression] Hi, Thanks David for reporting it. > > Thanks. > >> Source code is >> >> FAIL_IF(EV_CODE_EXTRACT(event.attr.config, sample & 0x3) != >> get_mmcra_sample_mode(get_reg_value(intr_regs, "MMCRA"), 4)); >> >> but >> >> #define EV_CODE_EXTRACT(x, y) \ >> ((x >> ev_shift_##y) & ev_mask_##y) >> >> >> Given the token pasting, I very much doubt an expression like "sample & 0x3" >> will work correctly. Same thing on the line above >> >> FAIL_IF(EV_CODE_EXTRACT(event.attr.config, sample >> 2) != >> get_mmcra_rand_samp_elig(get_reg_value(intr_regs, "MMCRA"), 4)); >> >> "sample >> 2" doesn't look like a valid token to me. > > It expands to: > > if event.attr.config >> ev_shift_sample >> 2) & ev_mask_sample >> 2) != > get_mmcra_rand_samp_elig(get_reg_value(intr_regs, "MMCRA"), 4))) > > Which AFAICS is valid, and does compile. > > Whether it's what the author actually intended is less clear. > > And the other example with & 0x3 seems obviously wrong, it expands to: > > if event.attr.config >> ev_shift_sample & 0x3) & ev_mask_sample & 0x3) > != get_mmcra_sample_mode(get_reg_value(intr_regs, "MMCRA"), 4))) > > The shift is 24, so bitwise anding it with 0x3 gets 0 which doesn't seem > likely to be what was intended. > Hi Michael, Thanks for checking it. The intention is to check 3 bits of rand_samp_elig field and 2 bits of rand_samp_mode field from the sampling bits. Basically we first want to extract that sample field using EV_CODE_EXTRACT macro and then fetch required value of rand_samp_elig and rand_samp_mode, to compare it with MMCRA bits. Right approach to do that would be: FAIL_IF((EV_CODE_EXTRACT(event.attr.config, sample) >> 2) != get_mmcra_rand_samp_elig(get_reg_value(intr_regs, "MMCRA"), 4)); FAIL_IF((EV_CODE_EXTRACT(event.attr.config, sample) & 0x3) != get_mmcra_rand_samp_elig(get_reg_value(intr_regs, "MMCRA"), 4)); I will send a fix patch for same. Thanks, Kajol Jain > cheers
Re: [PATCH] tools/perf/tests: Add system wide check for perf bench workload in all metric test
On 2/15/23 05:36, Ian Rogers wrote:
> On Tue, Feb 7, 2023 at 7:45 PM kajoljain wrote:
>>
>>
>>
>> On 2/6/23 10:10, Athira Rajeev wrote:
>>>
>>>
>>>> On 02-Feb-2023, at 10:14 PM, Kajol Jain wrote:
>>>>
>>>> Testcase stat_all_metrics.sh fails in powerpc:
>>>>
>>>> 92: perf all metrics test : FAILED!
>>>>
>>>> Logs with verbose:
>>>>
>>>> [command]# ./perf test 92 -vv
>>>> 92: perf all metrics test :
>>>> --- start ---
>>>> test child forked, pid 13262
>>>> Testing BRU_STALL_CPI
>>>> Testing COMPLETION_STALL_CPI
>>>>
>>>> Testing TOTAL_LOCAL_NODE_PUMPS_P23
>>>> Metric 'TOTAL_LOCAL_NODE_PUMPS_P23' not printed in:
>>>> Error:
>>>> Invalid event (hv_24x7/PM_PB_LNS_PUMP23,chip=3/) in per-thread mode,
>>>> enable system wide with '-a'.
>>>> Testing TOTAL_LOCAL_NODE_PUMPS_RETRIES_P01
>>>> Metric 'TOTAL_LOCAL_NODE_PUMPS_RETRIES_P01' not printed in:
>>>> Error:
>>>> Invalid event (hv_24x7/PM_PB_RTY_LNS_PUMP01,chip=3/) in per-thread mode,
>>>> enable system wide with '-a'.
>>>>
>>>>
>>>> Based on above logs, we could see some of the hv-24x7 metric events fails,
>>>> and logs suggest to run the metric event with -a option.
>>>> This change happened after the commit a4b8cfcabb1d ("perf stat: Delay
>>>> metric
>>>> parsing"), which delayed the metric parsing phase and now before metric
>>>> parsing
>>>> phase perf tool identifies, whether target is system-wide or not. With this
>>>> change, perf_event_open will fails with workload monitoring for uncore
>>>> events
>>>> as expected.
>>>>
>>>> The perf all metric test case fails as some of the hv-24x7 metric events
>>>> may need bigger workload to get the data. And the added perf bench
>>>> workload in 'perf all metric test case' will not run for hv-24x7 without
>>>> -a option.
>>>>
>>>> Fix this issue by adding system wide check for perf bench workload.
>>>>
>>>> Result with the patch changes in powerpc:
>>>>
>>>> 92: perf all metrics test : Ok
>>>>
>>>> Signed-off-by: Kajol Jain
>>>
>>> Looks good to me
>>>
>>> Reviewed-by: Athira Rajeev
>>
>> Hi Arnaldo,
>>Let me know if patch looks fine to you.
>>
>> Thanks,
>> Kajol Jain
>
> I ran into a similar issue but worked around it with:
>
> ```
> --- a/tools/perf/tests/shell/stat_all_metrics.sh
> +++ b/tools/perf/tests/shell/stat_all_metrics.sh
> @@ -11,7 +11,7 @@ for m in $(perf list --raw-dump metrics); do
> continue
> fi
> # Failed so try system wide.
> - result=$(perf stat -M "$m" -a true 2>&1)
> + result=$(perf stat -M "$m" -a sleep 0.01 2>&1)
> if [[ "$result" =~ "${m:0:50}" ]]
> then
> continue
> ```
>
> Running the synthesize benchmark is potentially slow, wdyt of the change
> above?
Hi Ian,
Thanks for reviewing the patch. Yes we can change workload true to
sleep 0.01 as we need bigger workload for 24x7 and sleep 0.01 will also
work for 24x7 metric events.
I will send v2 patch with this change.
Thanks,
Kajol Jain
>
> Thanks,
> Ian
>
>
>>>
>>>> ---
>>>> tools/perf/tests/shell/stat_all_metrics.sh | 7 +++
>>>> 1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/tools/perf/tests/shell/stat_all_metrics.sh
>>>> b/tools/perf/tests/shell/stat_all_metrics.sh
>>>> index 6e79349e42be..d49832a316d9 100755
>>>> --- a/tools/perf/tests/shell/stat_all_metrics.sh
>>>> +++ b/tools/perf/tests/shell/stat_all_metrics.sh
>>>> @@ -23,6 +23,13 @@ for m in $(perf list --raw-dump metrics); do
>>>> then
>>>> continue
>>>> fi
>>>> + # Failed again, possibly the event is uncore pmu event which will need
>>>> + # system wide monitoring with workload, so retry with -a option
>>>> + result=$(perf stat -M "$m" -a perf bench internals synthesize 2>&1)
>>>> + if [[ "$result" =~ "${m:0:50}" ]]
>>>> + then
>>>> +continue
>>>> + fi
>>>> echo "Metric '$m' not printed in:"
>>>> echo "$result"
>>>> if [[ "$err" != "1" ]]
>>>> --
>>>> 2.39.0
>>>>
>>>
Re: [PATCH] tools/perf/tests: Add system wide check for perf bench workload in all metric test
On 2/6/23 10:10, Athira Rajeev wrote:
>
>
>> On 02-Feb-2023, at 10:14 PM, Kajol Jain wrote:
>>
>> Testcase stat_all_metrics.sh fails in powerpc:
>>
>> 92: perf all metrics test : FAILED!
>>
>> Logs with verbose:
>>
>> [command]# ./perf test 92 -vv
>> 92: perf all metrics test :
>> --- start ---
>> test child forked, pid 13262
>> Testing BRU_STALL_CPI
>> Testing COMPLETION_STALL_CPI
>>
>> Testing TOTAL_LOCAL_NODE_PUMPS_P23
>> Metric 'TOTAL_LOCAL_NODE_PUMPS_P23' not printed in:
>> Error:
>> Invalid event (hv_24x7/PM_PB_LNS_PUMP23,chip=3/) in per-thread mode, enable
>> system wide with '-a'.
>> Testing TOTAL_LOCAL_NODE_PUMPS_RETRIES_P01
>> Metric 'TOTAL_LOCAL_NODE_PUMPS_RETRIES_P01' not printed in:
>> Error:
>> Invalid event (hv_24x7/PM_PB_RTY_LNS_PUMP01,chip=3/) in per-thread mode,
>> enable system wide with '-a'.
>>
>>
>> Based on above logs, we could see some of the hv-24x7 metric events fails,
>> and logs suggest to run the metric event with -a option.
>> This change happened after the commit a4b8cfcabb1d ("perf stat: Delay metric
>> parsing"), which delayed the metric parsing phase and now before metric
>> parsing
>> phase perf tool identifies, whether target is system-wide or not. With this
>> change, perf_event_open will fails with workload monitoring for uncore events
>> as expected.
>>
>> The perf all metric test case fails as some of the hv-24x7 metric events
>> may need bigger workload to get the data. And the added perf bench
>> workload in 'perf all metric test case' will not run for hv-24x7 without
>> -a option.
>>
>> Fix this issue by adding system wide check for perf bench workload.
>>
>> Result with the patch changes in powerpc:
>>
>> 92: perf all metrics test : Ok
>>
>> Signed-off-by: Kajol Jain
>
> Looks good to me
>
> Reviewed-by: Athira Rajeev
Hi Arnaldo,
Let me know if patch looks fine to you.
Thanks,
Kajol Jain
>
>> ---
>> tools/perf/tests/shell/stat_all_metrics.sh | 7 +++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/tools/perf/tests/shell/stat_all_metrics.sh
>> b/tools/perf/tests/shell/stat_all_metrics.sh
>> index 6e79349e42be..d49832a316d9 100755
>> --- a/tools/perf/tests/shell/stat_all_metrics.sh
>> +++ b/tools/perf/tests/shell/stat_all_metrics.sh
>> @@ -23,6 +23,13 @@ for m in $(perf list --raw-dump metrics); do
>> then
>> continue
>> fi
>> + # Failed again, possibly the event is uncore pmu event which will need
>> + # system wide monitoring with workload, so retry with -a option
>> + result=$(perf stat -M "$m" -a perf bench internals synthesize 2>&1)
>> + if [[ "$result" =~ "${m:0:50}" ]]
>> + then
>> +continue
>> + fi
>> echo "Metric '$m' not printed in:"
>> echo "$result"
>> if [[ "$err" != "1" ]]
>> --
>> 2.39.0
>>
>
Re: [PATCH] powerpc/hv-24x7: Fix pvr check when setting interface version
On 2/1/23 19:41, Sachin Sant wrote:
>
>
>> On 01-Feb-2023, at 12:18 AM, Kajol Jain wrote:
>>
>> Commit ec3eb9d941a9 ("powerpc/perf: Use PVR rather than
>> oprofile field to determine CPU version") added usage
>> of pvr value instead of oprofile field to determine the
>> platform. In hv-24x7 pmu driver code, pvr check uses PVR_POWER8
>> when assigning the interface version for power8 platform.
>> But power8 can also have other pvr values like PVR_POWER8E and
>> PVR_POWER8NVL. Hence the interface version won't be set
>> properly incase of PVR_POWER8E and PVR_POWER8NVL.
>> Fix this issue by adding the checks for PVR_POWER8E and
>> PVR_POWER8NVL as well.
>>
>> Fixes: ec3eb9d941a9 ("powerpc/perf: Use PVR rather than oprofile field to
>> determine CPU version")
>> Reported-by: Sachin Sant
>> Signed-off-by: Kajol Jain
>> ---
>
> Thanks for the fix. Tested on Power8 successfully.
> Tested-by: Sachin Sant
>
>> arch/powerpc/perf/hv-24x7.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
>> index 33c23225fd54..8c3253df133d 100644
>> --- a/arch/powerpc/perf/hv-24x7.c
>> +++ b/arch/powerpc/perf/hv-24x7.c
>> @@ -1727,7 +1727,8 @@ static int hv_24x7_init(void)
>> }
>>
>> /* POWER8 only supports v1, while POWER9 only supports v2. */
>> - if (PVR_VER(pvr) == PVR_POWER8)
>> + if (PVR_VER(pvr) == PVR_POWER8 || PVR_VER(pvr) == PVR_POWER8E ||
>> + PVR_VER(pvr) == PVR_POWER8NVL)
>
> Do we really need the check for Power8NV?
Hi Sachin,
Thanks for testing the patch. Here the NVL in POWER8NVL corresponds
to "NVLink" and its not related to PowerNV. PVR value used to specify
processor version which might be in used in any of pseries/powernv,
hence I added this check.
Thanks,
Kajol Jain
Re: [PATCH v5 00/15] jevents/pmu-events improvements
Patchset looks goot to me Reviewed-By: Kajol Jain On 1/27/23 05:06, Ian Rogers wrote: > Add an optimization to jevents using the metric code, rewrite metrics > in terms of each other in order to minimize size and improve > readability. For example, on Power8 > other_stall_cpi is rewritten from: > "PM_CMPLU_STALL / PM_RUN_INST_CMPL - PM_CMPLU_STALL_BRU_CRU / > PM_RUN_INST_CMPL - PM_CMPLU_STALL_FXU / PM_RUN_INST_CMPL - PM_CMPLU_STALL_VSU > / PM_RUN_INST_CMPL - PM_CMPLU_STALL_LSU / PM_RUN_INST_CMPL - > PM_CMPLU_STALL_NTCG_FLUSH / PM_RUN_INST_CMPL - PM_CMPLU_STALL_NO_NTF / > PM_RUN_INST_CMPL" > to: > "stall_cpi - bru_cru_stall_cpi - fxu_stall_cpi - vsu_stall_cpi - > lsu_stall_cpi - ntcg_flush_cpi - no_ntf_stall_cpi" > Which more closely matches the definition on Power9. > > A limitation of the substitutions are that they depend on strict > equality and the shape of the tree. This means that for "a + b + c" > then a substitution of "a + b" will succeed while "b + c" will fail > (the LHS for "+ c" is "a + b" not just "b"). > > Separate out the events and metrics in the pmu-events tables saving > 14.8% in the table size while making it that metrics no longer need to > iterate over all events and vice versa. These changes remove evsel's > direct metric support as the pmu_event no longer has a metric to > populate it. This is a minor issue as the code wasn't working > properly, metrics for this are rare and can still be properly ran > using '-M'. > > Add an ability to just build certain models into the jevents generated > pmu-metrics.c code. This functionality is appropriate for operating > systems like ChromeOS, that aim to minimize binary size and know all > the target CPU models. > > v5. s/list/List/ in a type annotation to fix Python 3.6 as reported by > John Garry . Fix a bug in metric_test.py > where a bad character was imported. To avoid similar regressions, > run metric_test.py before generating pmu-events.c. > v4. Better support the implementor/model style --model argument for > jevents.py. Add #slots test fix. On some patches add reviewed-by > John Garry and Kajol > Jain. > v3. Rebase an incorporate review comments from John Garry > , in particular breaking apart patch 4 > into 3 patches. The no jevents breakage and then later fix is > avoided in this series too. > v2. Rebase. Modify the code that skips rewriting a metric with the > same name with itself, to make the name check case insensitive. > > Ian Rogers (15): > perf jevents metric: Correct Function equality > perf jevents metric: Add ability to rewrite metrics in terms of others > perf jevents: Rewrite metrics in the same file with each other > perf pmu-events: Add separate metric from pmu_event > perf pmu-events: Separate the metrics from events for no jevents > perf pmu-events: Remove now unused event and metric variables > perf stat: Remove evsel metric_name/expr > perf jevents: Combine table prefix and suffix writing > perf pmu-events: Introduce pmu_metrics_table > perf jevents: Generate metrics and events as separate tables > perf jevents: Add model list option > perf pmu-events: Fix testing with JEVENTS_ARCH=all > perf jevents: Correct bad character encoding > tools build: Add test echo-cmd > perf jevents: Run metric_test.py at compile-time > > tools/build/Makefile.build | 1 + > tools/perf/arch/arm64/util/pmu.c | 11 +- > tools/perf/arch/powerpc/util/header.c| 4 +- > tools/perf/builtin-list.c| 20 +- > tools/perf/builtin-stat.c| 1 - > tools/perf/pmu-events/Build | 16 +- > tools/perf/pmu-events/empty-pmu-events.c | 108 ++- > tools/perf/pmu-events/jevents.py | 357 +++ > tools/perf/pmu-events/metric.py | 79 - > tools/perf/pmu-events/metric_test.py | 15 +- > tools/perf/pmu-events/pmu-events.h | 26 +- > tools/perf/tests/expand-cgroup.c | 4 +- > tools/perf/tests/parse-metric.c | 4 +- > tools/perf/tests/pmu-events.c| 69 ++--- > tools/perf/util/cgroup.c | 1 - > tools/perf/util/evsel.c | 2 - > tools/perf/util/evsel.h | 2 - > tools/perf/util/expr.h | 1 + > tools/perf/util/expr.l | 8 +- > tools/perf/util/metricgroup.c| 207 +++-- > tools/perf/util/metricgroup.h| 4 +- > tools/perf/util/parse-events.c | 2 - > tools/perf/util/pmu.c| 44 +-- > tools/perf/util/pmu.h| 10 +- > tools/perf/util/print-events.c | 32 +- > tools/perf/util/print-events.h | 3 +- > tools/perf/util/python.c | 7 - > tools/perf/util/stat-shadow.c| 112 --- > tools/perf/util/stat.h | 1 - > 29 files changed, 681 insertions(+), 470 deletions(-) > mode change
Re: [PATCH] powerpc/imc-pmu: Revert nest_init_lock to being a mutex
On 1/30/23 07:14, Michael Ellerman wrote:
> The recent commit 76d588dddc45 ("powerpc/imc-pmu: Fix use of mutex in
> IRQs disabled section") fixed warnings (and possible deadlocks) in the
> IMC PMU driver by converting the locking to use spinlocks.
>
> It also converted the init-time nest_init_lock to a spinlock, even
> though it's not used at runtime in IRQ disabled sections or while
> holding other spinlocks.
>
> This leads to warnings such as:
>
> BUG: sleeping function called from invalid context at
> include/linux/percpu-rwsem.h:49
> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0
> preempt_count: 1, expected: 0
> CPU: 7 PID: 1 Comm: swapper/0 Not tainted
> 6.2.0-rc2-14719-gf12cd06109f4-dirty #1
> Hardware name: Mambo,Simulated-System POWER9 0x4e1203 opal:v6.6.6 PowerNV
> Call Trace:
> dump_stack_lvl+0x74/0xa8 (unreliable)
> __might_resched+0x178/0x1a0
> __cpuhp_setup_state+0x64/0x1e0
> init_imc_pmu+0xe48/0x1250
> opal_imc_counters_probe+0x30c/0x6a0
> platform_probe+0x78/0x110
> really_probe+0x104/0x420
> __driver_probe_device+0xb0/0x170
> driver_probe_device+0x58/0x180
> __driver_attach+0xd8/0x250
> bus_for_each_dev+0xb4/0x140
> driver_attach+0x34/0x50
> bus_add_driver+0x1e8/0x2d0
> driver_register+0xb4/0x1c0
> __platform_driver_register+0x38/0x50
> opal_imc_driver_init+0x2c/0x40
> do_one_initcall+0x80/0x360
> kernel_init_freeable+0x310/0x3b8
> kernel_init+0x30/0x1a0
> ret_from_kernel_thread+0x5c/0x64
>
> Fix it by converting nest_init_lock back to a mutex, so that we can call
> sleeping functions while holding it. There is no interaction between
> nest_init_lock and the runtime spinlocks used by the actual PMU routines.
Thanks for the patch. Patch looks good to me.
Reviewed-by: Kajol Jain
Tested-by: Kajol Jain
Thanks,
Kajol Jain
>
> Fixes: 76d588dddc45 ("powerpc/imc-pmu: Fix use of mutex in IRQs disabled
> section")
> Signed-off-by: Michael Ellerman
> ---
> arch/powerpc/perf/imc-pmu.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
> index 100e97daf76b..9d229ef7f86e 100644
> --- a/arch/powerpc/perf/imc-pmu.c
> +++ b/arch/powerpc/perf/imc-pmu.c
> @@ -22,7 +22,7 @@
> * Used to avoid races in counting the nest-pmu units during hotplug
> * register and unregister
> */
> -static DEFINE_SPINLOCK(nest_init_lock);
> +static DEFINE_MUTEX(nest_init_lock);
> static DEFINE_PER_CPU(struct imc_pmu_ref *, local_nest_imc_refc);
> static struct imc_pmu **per_nest_pmu_arr;
> static cpumask_t nest_imc_cpumask;
> @@ -1629,7 +1629,7 @@ static void imc_common_mem_free(struct imc_pmu *pmu_ptr)
> static void imc_common_cpuhp_mem_free(struct imc_pmu *pmu_ptr)
> {
> if (pmu_ptr->domain == IMC_DOMAIN_NEST) {
> - spin_lock(_init_lock);
> + mutex_lock(_init_lock);
> if (nest_pmus == 1) {
>
> cpuhp_remove_state(CPUHP_AP_PERF_POWERPC_NEST_IMC_ONLINE);
> kfree(nest_imc_refc);
> @@ -1639,7 +1639,7 @@ static void imc_common_cpuhp_mem_free(struct imc_pmu
> *pmu_ptr)
>
> if (nest_pmus > 0)
> nest_pmus--;
> - spin_unlock(_init_lock);
> + mutex_unlock(_init_lock);
> }
>
> /* Free core_imc memory */
> @@ -1796,11 +1796,11 @@ int init_imc_pmu(struct device_node *parent, struct
> imc_pmu *pmu_ptr, int pmu_id
> * rest. To handle the cpuhotplug callback unregister, we track
> * the number of nest pmus in "nest_pmus".
> */
> - spin_lock(_init_lock);
> + mutex_lock(_init_lock);
> if (nest_pmus == 0) {
> ret = init_nest_pmu_ref();
> if (ret) {
> - spin_unlock(_init_lock);
> + mutex_unlock(_init_lock);
> kfree(per_nest_pmu_arr);
> per_nest_pmu_arr = NULL;
> goto err_free_mem;
> @@ -1808,7 +1808,7 @@ int init_imc_pmu(struct device_node *parent, struct
> imc_pmu *pmu_ptr, int pmu_id
> /* Register for cpu hotplug notification. */
> ret = nest_pmu_cpumask_init();
> if (ret) {
> - spin_unlock(_init_lock);
> + mutex_unlock(_init_lock);
> kfree(nest_imc_refc);
> kfree(per_nest_pmu_arr);
> per_nest_pmu_arr = NULL;
> @@ -1816,7 +1816,7 @@ int init_imc_pmu(struct device_node *parent, struct
> imc_pmu *pmu_ptr, int pmu_id
> }
> }
> nest_pmus++;
> - spin_unlock(_init_lock);
> + mutex_unlock(_init_lock);
>
Re: [PATCH v3 01/11] perf jevents metric: Correct Function equality
On 1/24/23 12:03, Ian Rogers wrote: > rhs may not be defined, say for source_count, so add a guard. > > Signed-off-by: Ian Rogers > --- > tools/perf/pmu-events/metric.py | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/tools/perf/pmu-events/metric.py b/tools/perf/pmu-events/metric.py > index 4797ed4fd817..2f2fd220e843 100644 > --- a/tools/perf/pmu-events/metric.py > +++ b/tools/perf/pmu-events/metric.py > @@ -261,8 +261,10 @@ class Function(Expression): > >def Equals(self, other: Expression) -> bool: > if isinstance(other, Function): > - return self.fn == other.fn and self.lhs.Equals( > - other.lhs) and self.rhs.Equals(other.rhs) > + result = self.fn == other.fn and self.lhs.Equals(other.lhs) > + if self.rhs: > +result = result and self.rhs.Equals(other.rhs) > + return result > return False > > Patch looks good to me. Reviewed-by: Kajol Jain Thanks, Kajol Jain
Re: [PATCH v2] powerpc/hv-gpci: Fix hv_gpci event list
On 11/24/22 17:18, Michael Ellerman wrote:
> Kajol Jain writes:
>> Based on getPerfCountInfo v1.018 documentation, some of the
>> hv_gpci events got deprecated for platforms firmware that
> ^ ^
> were platform
>
>> supports counter_info_version 0x8 or above.
>>
>> Patch fixes the hv_gpci event list by adding a new attribute
> ^
> Fix the ...
>
>> group called "hv_gpci_event_attrs_v6" and a "EVENT_ENABLE"
>
> Can we please give that macro a more descriptive name?
>
> EVENT_ENABLE implies it enables/disables all events, but it's only
> certain ones.
Hi Michael,
Thanks for the review comments, I will make these changes in next
version.
Thanks,
Kajol Jain
>
>> macro to enable these events for platform firmware
>> that supports counter_info_version 0x6 or below. And assigning
>> the hv_gpci event list based on output counter info version
>> of underlying plaform.
>>
>> Fixes: 97bf2640184f ("powerpc/perf/hv-gpci: add the remaining gpci requests")
>> Signed-off-by: Kajol Jain
>> Reviewed-by: Madhavan Srinivasan
>> ---
>> Changelog:
>>
>> v1 -> v2
>> - As suggested by Michael Ellerman, using counter_info_version value
>> rather then cpu_has_feature() to assign hv-gpci event list.
>>
>> arch/powerpc/perf/hv-gpci-requests.h | 4
>> arch/powerpc/perf/hv-gpci.c | 35 ++--
>> arch/powerpc/perf/hv-gpci.h | 1 +
>> arch/powerpc/perf/req-gen/perf.h | 17 ++
>> 4 files changed, 55 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/perf/hv-gpci-requests.h
>> b/arch/powerpc/perf/hv-gpci-requests.h
>> index 8965b4463d43..baef3d082de9 100644
>> --- a/arch/powerpc/perf/hv-gpci-requests.h
>> +++ b/arch/powerpc/perf/hv-gpci-requests.h
>> @@ -79,6 +79,7 @@ REQUEST(__field(0, 8, partition_id)
>> )
>> #include I(REQUEST_END)
>>
>> +#ifdef EVENT_ENABLE
>> /*
>> * Not available for counter_info_version >= 0x8, use
>> * run_instruction_cycles_by_partition(0x100) instead.
>> @@ -92,6 +93,7 @@ REQUEST(__field(0, 8, partition_id)
>> __count(0x10, 8, cycles)
>> )
>> #include I(REQUEST_END)
>> +#endif
>>
>> #define REQUEST_NAME system_performance_capabilities
>> #define REQUEST_NUM 0x40
>> @@ -103,6 +105,7 @@ REQUEST(__field(0, 1, perf_collect_privileged)
>> )
>> #include I(REQUEST_END)
>>
>> +#ifdef EVENT_ENABLE
>> #define REQUEST_NAME processor_bus_utilization_abc_links
>> #define REQUEST_NUM 0x50
>> #define REQUEST_IDX_KIND "hw_chip_id=?"
>> @@ -194,6 +197,7 @@ REQUEST(__field(0, 4, phys_processor_idx)
>> __count(0x28, 8, instructions_completed)
>> )
>> #include I(REQUEST_END)
>> +#endif
>>
>> /* Processor_core_power_mode (0x95) skipped, no counters */
>> /* Affinity_domain_information_by_virtual_processor (0xA0) skipped,
>> diff --git a/arch/powerpc/perf/hv-gpci.c b/arch/powerpc/perf/hv-gpci.c
>> index 5eb60ed5b5e8..6eeabf3975e5 100644
>> --- a/arch/powerpc/perf/hv-gpci.c
>> +++ b/arch/powerpc/perf/hv-gpci.c
>> @@ -70,9 +70,9 @@ static const struct attribute_group format_group = {
>> .attrs = format_attrs,
>> };
>>
>> -static const struct attribute_group event_group = {
>> +static struct attribute_group event_group = {
>> .name = "events",
>> -.attrs = hv_gpci_event_attrs,
>> +/* .attrs is set in init */
>> };
>>
>> #define HV_CAPS_ATTR(_name, _format)\
>> @@ -330,6 +330,7 @@ static int hv_gpci_init(void)
>> int r;
>> unsigned long hret;
>> struct hv_perf_caps caps;
>> +struct hv_gpci_request_buffer *arg;
>>
>> hv_gpci_assert_offsets_correct();
>>
>> @@ -353,6 +354,36 @@ static int hv_gpci_init(void)
>> /* sampling not supported */
>> h_gpci_pmu.capabilities |= PERF_PMU_CAP_NO_INTERRUPT;
>>
>> +arg = (void *)get_cpu_var(hv_gpci_reqb);
>> +memset(arg, 0, HGPCI_REQ_BUFFER_SIZE);
>> +
>> +/*
>> + * hcall H_GET_PERF_COUNTER_INFO populates the output
>> + * counter_info_version value based on the system hypervisor.
>> + * Pass the counter request 0x10 corresponds to request type
> ^
> which
>> + * 'Dispatch_timebase_by_processor', to get the supported
>> + * counter_info_version.
>> + */
>> +arg->params.counter_request = cpu_to_be32(0x10);
>> +
>> +r = plpar_hcall_norets(H_GET_PERF_COUNTER_INFO,
>> +virt_to_phys(arg), HGPCI_REQ_BUFFER_SIZE);
>> +if (r) {
>> +pr_devel("hcall failed, can't get supported
>> counter_info_version: 0x%x\n", r);
>> +arg->params.counter_info_version_out = 0x8;
>> +}
>> +
>> +/*
>> + * Use counter_info_version_out value to assign
>> + * required hv-gpci event list.
>> + */
>> +if (arg->params.counter_info_version_out >= 0x8)
>> +event_group.attrs =
Re: [PATCH] perf test: Skip watchpoint tests if no watchpoints available
On 11/21/22 15:57, Naveen N. Rao wrote:
> On IBM Power9, perf watchpoint tests fail since no hardware breakpoints
> are available. Detect this by checking the error returned by
> perf_event_open() and skip the tests in that case.
>
> Reported-by: Disha Goel
> Signed-off-by: Naveen N. Rao
> ---
Patch looks fine to me. Also tested it in power9 box
Test result without this patch changes :
23: Watchpoint :
23.1: Read Only Watchpoint: FAILED!
23.2: Write Only Watchpoint : FAILED!
23.3: Read / Write Watchpoint : FAILED!
23.4: Modify Watchpoint : FAILED!
Test result with patch changes:
23: Watchpoint :
23.1: Read Only Watchpoint: Skip (missing hardware support)
23.2: Write Only Watchpoint : Skip (missing hardware support)
23.3: Read / Write Watchpoint : Skip (missing hardware support)
23.4: Modify Watchpoint : Skip (missing hardware support)
Reviewed-by: Kajol Jain
Tested-by: Kajol Jain
Thanks,
Kajol Jain
> tools/perf/tests/wp.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/tools/perf/tests/wp.c b/tools/perf/tests/wp.c
> index 56455da30341b4..cc8719609b19ea 100644
> --- a/tools/perf/tests/wp.c
> +++ b/tools/perf/tests/wp.c
> @@ -59,8 +59,10 @@ static int __event(int wp_type, void *wp_addr, unsigned
> long wp_len)
> get__perf_event_attr(, wp_type, wp_addr, wp_len);
> fd = sys_perf_event_open(, 0, -1, -1,
>perf_event_open_cloexec_flag());
> - if (fd < 0)
> + if (fd < 0) {
> + fd = -errno;
> pr_debug("failed opening event %x\n", attr.bp_type);
> + }
>
> return fd;
> }
> @@ -77,7 +79,7 @@ static int test__wp_ro(struct test_suite *test
> __maybe_unused,
>
> fd = __event(HW_BREAKPOINT_R, (void *), sizeof(data1));
> if (fd < 0)
> - return -1;
> + return fd == -ENODEV ? TEST_SKIP : -1;
>
> tmp = data1;
> WP_TEST_ASSERT_VAL(fd, "RO watchpoint", 1);
> @@ -101,7 +103,7 @@ static int test__wp_wo(struct test_suite *test
> __maybe_unused,
>
> fd = __event(HW_BREAKPOINT_W, (void *), sizeof(data1));
> if (fd < 0)
> - return -1;
> + return fd == -ENODEV ? TEST_SKIP : -1;
>
> tmp = data1;
> WP_TEST_ASSERT_VAL(fd, "WO watchpoint", 0);
> @@ -126,7 +128,7 @@ static int test__wp_rw(struct test_suite *test
> __maybe_unused,
> fd = __event(HW_BREAKPOINT_R | HW_BREAKPOINT_W, (void *),
>sizeof(data1));
> if (fd < 0)
> - return -1;
> + return fd == -ENODEV ? TEST_SKIP : -1;
>
> tmp = data1;
> WP_TEST_ASSERT_VAL(fd, "RW watchpoint", 1);
> @@ -150,7 +152,7 @@ static int test__wp_modify(struct test_suite *test
> __maybe_unused, int subtest _
>
> fd = __event(HW_BREAKPOINT_W, (void *), sizeof(data1));
> if (fd < 0)
> - return -1;
> + return fd == -ENODEV ? TEST_SKIP : -1;
>
> data1 = tmp;
> WP_TEST_ASSERT_VAL(fd, "Modify watchpoint", 1);
>
> base-commit: 63a3bf5e8d9e79ce456c8f73d4395a5a51d841b1
Re: [PATCH 1/2] tools/perf: Fix printing os->prefix in CSV metrics output
On 11/4/22 13:07, Disha Goel wrote:
> On 11/4/22 12: 59 PM, Athira Rajeev wrote: On 03-Nov-2022, at 9: 45 PM,
> Ian Rogers wrote: On Wed, Nov 2, 2022 at 1: 36 AM
> Athira Rajeev
>
>
>
>
>
> On 11/4/22 12:59 PM, Athira Rajeev wrote:
>>> On 03-Nov-2022, at 9:45 PM, Ian Rogers wrote:
>>>
>>> On Wed, Nov 2, 2022 at 1:36 AM Athira Rajeev
>>> wrote:
> On 18-Oct-2022, at 2:26 PM, Athira Rajeev
> wrote:
>
> Perf stat with CSV output option prints an extra empty
> string as first field in metrics output line.
> Sample output below:
>
> # ./perf stat -x, --per-socket -a -C 1 ls
> S0,1,1.78,msec,cpu-clock,1785146,100.00,0.973,CPUs utilized
> S0,1,26,,context-switches,1781750,100.00,0.015,M/sec
> S0,1,1,,cpu-migrations,1780526,100.00,0.561,K/sec
> S0,1,1,,page-faults,1779060,100.00,0.561,K/sec
> S0,1,875807,,cycles,1769826,100.00,0.491,GHz
> S0,1,85281,,stalled-cycles-frontend,1767512,100.00,9.74,frontend
> cycles idle
> S0,1,576839,,stalled-cycles-backend,1766260,100.00,65.86,backend
> cycles idle
> S0,1,288430,,instructions,1762246,100.00,0.33,insn per cycle
> > ,S0,1,,,2.00,stalled cycles per insn
>
> The above command line uses field separator as ","
> via "-x," option and per-socket option displays
> socket value as first field. But here the last line
> for "stalled cycles per insn" has "," in the
> beginning.
>
> Sample output using interval mode:
> # ./perf stat -I 1000 -x, --per-socket -a -C 1 ls
> 0.001813453,S0,1,1.87,msec,cpu-clock,1872052,100.00,0.002,CPUs
> utilized
> 0.001813453,S0,1,2,,context-switches,1868028,100.00,1.070,K/sec
> --
> 0.001813453,S0,1,85379,,instructions,1856754,100.00,0.32,insn per
> cycle
> > 0.001813453,,S0,1,,,1.34,stalled cycles per insn
>
> Above result also has an extra csv separator after
> the timestamp. Patch addresses extra field separator
> in the beginning of the metric output line.
>
> The counter stats are displayed by function
> "perf_stat__print_shadow_stats" in code
> "util/stat-shadow.c". While printing the stats info
> for "stalled cycles per insn", function "new_line_csv"
> is used as new_line callback.
>
> The new_line_csv function has check for "os->prefix"
> and if prefix is not null, it will be printed along
> with cvs separator.
> Snippet from "new_line_csv":
> if (os->prefix)
> fprintf(os->fh, "%s%s", os->prefix, config->csv_sep);
>
> Here os->prefix gets printed followed by ","
> which is the cvs separator. The os->prefix is
> used in interval mode option ( -I ), to print
> time stamp on every new line. But prefix is
> already set to contain csv separator when used
> in interval mode for csv option.
>
> Reference: Function "static void print_interval"
> Snippet:
> sprintf(prefix, "%6lu.%09lu%s", ts->tv_sec, ts->tv_nsec,
> config->csv_sep);
>
> Also if prefix is not assigned (if not used with
> -I option), it gets set to empty string.
> Reference: function printout() in util/stat-display.c
> Snippet:
> .prefix = prefix ? prefix : "",
>
> Since prefix already set to contain cvs_sep in interval
> option, patch removes printing config->csv_sep in
> new_line_csv function to avoid printing extra field.
>
> After the patch:
>
> # ./perf stat -x, --per-socket -a -C 1 ls
> S0,1,2.04,msec,cpu-clock,2045202,100.00,1.013,CPUs utilized
> S0,1,2,,context-switches,2041444,100.00,979.289,/sec
> S0,1,0,,cpu-migrations,2040820,100.00,0.000,/sec
> S0,1,2,,page-faults,2040288,100.00,979.289,/sec
> S0,1,254589,,cycles,2036066,100.00,0.125,GHz
> S0,1,82481,,stalled-cycles-frontend,2032420,100.00,32.40,frontend
> cycles idle
> S0,1,113170,,stalled-cycles-backend,2031722,100.00,44.45,backend
> cycles idle
> S0,1,88766,,instructions,2030942,100.00,0.35,insn per cycle
> S0,1,,,1.27,stalled cycles per insn
>
> Fixes: 92a61f6412d3 ("perf stat: Implement CSV metrics output")
> Reported-by: Disha Goel
> Signed-off-by: Athira Rajeev
>
> perf stat csv test passed after applying the patch
> Tested-by: Disha Goel
Hi,
Patch looks fine to me.
Reviewed-By: Kajol Jain
Thanks,
Kajol Jain
>
Hi All,
Looking for review comments for this change.
>>> Hi,
>>>
>>> Thanks for addressing issues in this code. What is the status of the
>>> CSV output test following these changes?
>>>
>>> I think going forward we need to move away from CSV and columns, to
>>> something with
Re: [PATCH 3/3] tools/testing/selftests/powerpc: Update the bhrb filter sampling test to test for multiple branch filters
On 9/13/22 17:25, Athira Rajeev wrote: > For PERF_SAMPLE_BRANCH_STACK sample type, different branch_sample_type, > ie branch filters are supported. The testcase "bhrb_filter_map_test" > tests the valid and invalid filter maps in different powerpc platforms. > Update this testcase to include scenario to cover multiple branch > filters at sametime. Since powerpc doesn't support multiple filters at > sametime, expect failure during perf_event_open. > > Reported-by: Disha Goel > Signed-off-by: Athira Rajeev > --- > .../powerpc/pmu/sampling_tests/bhrb_filter_map_test.c| 9 + > 1 file changed, 9 insertions(+) > > diff --git > a/tools/testing/selftests/powerpc/pmu/sampling_tests/bhrb_filter_map_test.c > b/tools/testing/selftests/powerpc/pmu/sampling_tests/bhrb_filter_map_test.c > index 8182647c63c8..605669d4e4cb 100644 > --- > a/tools/testing/selftests/powerpc/pmu/sampling_tests/bhrb_filter_map_test.c > +++ > b/tools/testing/selftests/powerpc/pmu/sampling_tests/bhrb_filter_map_test.c > @@ -96,6 +96,15 @@ static int bhrb_filter_map_test(void) > } > } > Patch looks good to me. Reviewed-By: Kajol Jain Thanks, Kajol Jain > + /* > + * Combine filter maps which includes a valid branch filter and an > invalid branch > + * filter. Example: any ( PERF_SAMPLE_BRANCH_ANY) and save_type > + * (PERF_SAMPLE_BRANCH_TYPE_SAVE). > + * The perf_event_open should fail in this case. > + */ > + event.attr.branch_sample_type = PERF_SAMPLE_BRANCH_ANY | > PERF_SAMPLE_BRANCH_TYPE_SAVE; > + FAIL_IF(!event_open()); > + > return 0; > } >
Re: [PATCH 2/3] tools/perf/tests: Fix branch stack sampling test to include sanity check for branch filter
On 9/13/22 17:25, Athira Rajeev wrote:
> commit b55878c90ab9 ("perf test: Add test for branch stack sampling")
> added test for branch stack sampling. There is a sanity check in the
> beginning to skip the test if the hardware doesn't support branch stack
> sampling.
>
> Snippet
> <<>>
> skip the test if the hardware doesn't support branch stack sampling
> perf record -b -o- -B true > /dev/null 2>&1 || exit 2
> <<>>
>
> But the testcase also uses branch sample types: save_type, any. if any
> platform doesn't support the branch filters used in the test, the testcase
> will fail. In powerpc, currently mutliple branch filters are not supported
> and hence this test fails in powerpc. Fix the sanity check to look at
> the support for branch filters used in this test before proceeding with
> the test.
>
> Fixes: b55878c90ab9 ("perf test: Add test for branch stack sampling")
> Reported-by: Disha Goel
> Signed-off-by: Athira Rajeev
Patch looks good to me.
Reviewed-By: Kajol Jain
Thanks,
Kajol Jain
> ---
> tools/perf/tests/shell/test_brstack.sh | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/tests/shell/test_brstack.sh
> b/tools/perf/tests/shell/test_brstack.sh
> index c644f94a6500..ec801cffae6b 100755
> --- a/tools/perf/tests/shell/test_brstack.sh
> +++ b/tools/perf/tests/shell/test_brstack.sh
> @@ -12,7 +12,8 @@ if ! [ -x "$(command -v cc)" ]; then
> fi
>
> # skip the test if the hardware doesn't support branch stack sampling
> -perf record -b -o- -B true > /dev/null 2>&1 || exit 2
> +# and if the architecture doesn't support filter types: any,save_type,u
> +perf record -b -o- -B --branch-filter any,save_type,u true > /dev/null 2>&1
> || exit 2
>
> TMPDIR=$(mktemp -d /tmp/__perf_test.program.X)
>
Re: [PATCH 1/3] powerpc/perf: Fix branch_filter support for multiple filters in powerpc
On 9/16/22 17:02, Disha Goel wrote:
>
> On 9/13/22 5:25 PM, Athira Rajeev wrote:
>> For PERF_SAMPLE_BRANCH_STACK sample type, different branch_sample_type
>> ie branch filters are supported. The branch filters are requested via
>> event attribute "branch_sample_type". Multiple branch filters can be
>> passed in event attribute.
>>
>> Example:
>> perf record -b -o- -B --branch-filter any,ind_call true
>>
>> Powerpc does not support having multiple branch filters at
>> sametime. In powerpc, branch filters for branch stack sampling
>> is set via MMCRA IFM bits [32:33]. But currently when requesting
>> for multiple filter types, the "perf record" command does not
>> report any error.
>>
>> Example:
>> perf record -b -o- -B --branch-filter any,save_type true
>> perf record -b -o- -B --branch-filter any,ind_call true
>>
>> The "bhrb_filter_map" function in PMU driver code does the
>> validity check for supported branch filters. But this check
>> is done for single filter. Hence "perf record" will proceed
>> here without reporting any error.
>>
>> Fix power_pmu_event_init to return EOPNOTSUPP when multiple
>> branch filters are requested in the event attr.
>>
>> After the fix:
>> perf record --branch-filter any,ind_call -- ls
>> Error:
>> cycles: PMU Hardware doesn't support sampling/overflow-interrupts.
>> Try 'perf stat'
>>
>> Reported-by: Disha Goel
>> Signed-off-by: Athira Rajeev
>> Reviewed-by: Madhavan Srinivasan
>
> Tested-by: Disha Goel
Patch looks good to me.
Reviewed-By: Kajol Jain
Thanks,
Kajol Jain
>
>> ---
>> arch/powerpc/perf/core-book3s.c | 15 +++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/arch/powerpc/perf/core-book3s.c
>> b/arch/powerpc/perf/core-book3s.c
>> index 13919eb96931..2c2d235cb8d8 100644
>> --- a/arch/powerpc/perf/core-book3s.c
>> +++ b/arch/powerpc/perf/core-book3s.c
>> @@ -2131,6 +2131,21 @@ static int power_pmu_event_init(struct perf_event
>> *event)
>> if (has_branch_stack(event)) {
>> u64 bhrb_filter = -1;
>>
>> +/*
>> + * powerpc does not support having multiple branch filters
>> + * at sametime. Branch filters are set via MMCRA IFM[32:33]
>> + * bits for power8 and above. Return EOPNOTSUPP when multiple
>> + * branch filters are requested in the event attr.
>> + *
>> + * When opening event via perf_event_open, branch_sample_type
>> + * gets adjusted in perf_copy_attr function. Kernel will
>> + * automatically adjust the branch_sample_type based on the
>> + * event modifier settings to include
>> PERF_SAMPLE_BRANCH_PLM_ALL.
>> + * Hence drop the check for PERF_SAMPLE_BRANCH_PLM_ALL.
>> + */
>> +if (hweight64(event->attr.branch_sample_type &
>> ~PERF_SAMPLE_BRANCH_PLM_ALL) > 1)
>> +return -EOPNOTSUPP;
>> +
>> if (ppmu->bhrb_filter_map)
>> bhrb_filter = ppmu->bhrb_filter_map(
>> event->attr.branch_sample_type);
Re: [PATCH V2] tools/perf/tests: Fix perf probe error log check in skip_if_no_debuginfo
On 9/16/22 16:19, Athira Rajeev wrote:
> The perf probe related tests like probe_vfs_getname.sh which
> is in "tools/perf/tests/shell" directory have dependency on
> debuginfo information in the kernel. Currently debuginfo
> check is handled by skip_if_no_debuginfo function in the
> file "lib/probe_vfs_getname.sh". skip_if_no_debuginfo function
> looks for this specific error log from perf probe to skip
> the testcase:
>
> <<>>
> Failed to find the path for the kernel|Debuginfo-analysis is
> not supported
> <>>
>
> But in some case, like this one in powerpc, while running this
> test, observed error logs is:
>
> <<>>
> The /lib/modules//build/vmlinux file has no debug information.
> Rebuild with CONFIG_DEBUG_INFO=y, or install an appropriate debuginfo
> package.
> Error: Failed to add events.
> <<>>
>
> Update the skip_if_no_debuginfo function to include the above
> error, to skip the test in these scenarios too.
Patch looks good to me.
Reviewed-By: Kajol Jain
Thanks,
Kajol Jain
>
> Reported-by: Disha Goel
> Signed-off-by: Athira Rajeev
> ---
> changelog:
> v1 -> v2:
> Corrected formatting of spaces in error log.
> With spaces in v1 of the patch, the egrep search was
> considering spaces also.
>
> tools/perf/tests/shell/lib/probe_vfs_getname.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/perf/tests/shell/lib/probe_vfs_getname.sh
> b/tools/perf/tests/shell/lib/probe_vfs_getname.sh
> index 5b17d916c555..b616d42bd19d 100644
> --- a/tools/perf/tests/shell/lib/probe_vfs_getname.sh
> +++ b/tools/perf/tests/shell/lib/probe_vfs_getname.sh
> @@ -19,6 +19,6 @@ add_probe_vfs_getname() {
> }
>
> skip_if_no_debuginfo() {
> - add_probe_vfs_getname -v 2>&1 | egrep -q "^(Failed to find the path for
> the kernel|Debuginfo-analysis is not supported)" && return 2
> + add_probe_vfs_getname -v 2>&1 | egrep -q "^(Failed to find the path for
> the kernel|Debuginfo-analysis is not supported)|(file has no debug
> information)" && return 2
> return 1
> }
Re: [PATCH v2] powerpc/papr_scm: Fix nvdimm event mappings
On 7/12/22 10:45, Vaibhav Jain wrote:
> Hi Kajol,
>
> Thanks for the patch. Minor review comment below:
>
> Kajol Jain writes:
>
>> Commit 4c08d4bbc089 ("powerpc/papr_scm: Add perf interface support")
>> added performance monitoring support for papr-scm nvdimm devices via
>> perf interface. Commit also added an array in papr_scm_priv
>> structure called "nvdimm_events_map", which got filled based on the
>> result of H_SCM_PERFORMANCE_STATS hcall.
>>
>> Currently there is an assumption that the order of events in the
>> stats buffer, returned by the hypervisor is same. And that order also
>> matches with the events specified in nvdimm driver code.
>> But this assumption is not documented anywhere in Power Architecture
>> Platform Requirements (PAPR) document. Although the order
>> of events happens to be same on current systems, but it might
>> not be true in future generation systems. Fix the issue, by
>> adding a static mapping for nvdimm events to corresponding stat-id,
>> and removing the dynamic map from papr_scm_priv structure.
>>
>> Fixes: 4c08d4bbc089 ("powerpc/papr_scm: Add perf interface support")
>> Reported-by: Aneesh Kumar K.V
>> Signed-off-by: Kajol Jain
>
>
>> @@ -460,10 +480,9 @@ static void papr_scm_pmu_del(struct perf_event *event,
>> int flags)
>>
>> static int papr_scm_pmu_check_events(struct papr_scm_priv *p, struct
>> nvdimm_pmu *nd_pmu)
>> {
>> -struct papr_scm_perf_stat *stat;
>> struct papr_scm_perf_stats *stats;
>> u32 available_events;
>> -int index, rc = 0;
>> +int rc;
>>
>> if (!p->stat_buffer_len)
>> return -ENOENT;
>> @@ -476,34 +495,12 @@ static int papr_scm_pmu_check_events(struct
>> papr_scm_priv *p, struct nvdimm_pmu
>> /* Allocate the buffer for phyp where stats are written */
>> stats = kzalloc(p->stat_buffer_len, GFP_KERNEL);
>> if (!stats) {
>> -rc = -ENOMEM;
>> -return rc;
>> +return -ENOMEM;
>> }
>>
>> /* Called to get list of events supported */
>> rc = drc_pmem_query_stats(p, stats, 0);
>> -if (rc)
>> -goto out;
>> -
>> -/*
>> - * Allocate memory and populate nvdimm_event_map.
>> - * Allocate an extra element for NULL entry
>> - */
>> -p->nvdimm_events_map = kcalloc(available_events + 1,
>> - sizeof(stat->stat_id),
>> - GFP_KERNEL);
>> -if (!p->nvdimm_events_map) {
>> -rc = -ENOMEM;
>> -goto out;
>> -}
>>
>> -/* Copy all stat_ids to event map */
>> -for (index = 0, stat = stats->scm_statistic;
>> - index < available_events; index++, ++stat) {
>> -memcpy(>nvdimm_events_map[index * sizeof(stat->stat_id)],
>> - >stat_id, sizeof(stat->stat_id));
>> -}
>> -out:
>> kfree(stats);
>> return rc;
>> }
>
> Earlier implementation of papr_scm_pmu_check_events() would copy the
> contents of returned stat-ids to struct papr_scm_priv->nvdimm_events_map,
> hence it was needed.
>
> With static events map you dont really need to call
> drc_pmem_query_stats() as that would have been already being done once
> in papr_scm_probe() before papr_scm_pmu_register() is called:
>
>
Hi Vaibhav,
Thanks for reviewing the patch. Yes it make sense, as mainly we want
to make sure, in case stat buffer is empty we will not register the
nvdimm pmu. I will do the change and send next version of the patch.
Thanks,
Kajol Jain
> papr_scm_probe()
> {
> ...
> /* Try retrieving the stat buffer and see if its supported */
> stat_size = drc_pmem_query_stats(p, NULL, 0);
> ...
> papr_scm_pmu_register(p);
> ...
> }
>
> I would suggest replacing single callsite of papr_scm_pmu_check_events()
> with the check
>
> if (!p->stat_buffer_len)
> goto pmu_check_events_err;
>
>
>
Re: [PATCH] powerpc/papr_scm: Fix nvdimm event mappings
On 6/27/22 12:05, Michael Ellerman wrote:
> Hi Kajol,
>
> A few comments below ...
Hi Michael,
Thanks for reviewing the patch. I will make the changes suggested by
you and send version 2 of this patch.
Thanks,
Kajol Jain
>
> Kajol Jain writes:
>> Commit 4c08d4bbc089 ("powerpc/papr_scm: Add perf interface support")
>> adds performance monitoring support for papr-scm nvdimm devices via
> ^
> We're talking about a commit that's already happened so we should use
> past tense, so "added".
>
>> perf interface. It also adds one array in papr_scm_priv
> "added"
>> structure called "nvdimm_events_map", to dynamically save the stat_id
>> for events specified in nvdimm driver code "nd_perf.c".
>>
>> Right now the mapping is done based on the result of
>> H_SCM_PERFORMANCE_STATS hcall, when all the stats are
>> requested. Currently there is an assumption, that a
>> certain stat will always be found at a specific offset
>> in the stat buffer.
> ^
> "returned by the hypervisor."
>
> To make it clear where the stat buffer comes from, and that it's out of
> our control.
>
>> The assumption may not be true or documented as part of PAPR
>> documentation.
>
> That reads as the assumption "may not be documented as part of PAPR". I
> think what you mean is the assumption *is not* documented by PAPR, and
> although it happens to be true on current systems it may not be true in
> future.
>
>> Fixing it, by adding a static mapping for nvdimm events to
> Fix it
>> corresponding stat-id, and removing the map from
>> papr_scm_priv structure.
>>
>> Fixes: 4c08d4bbc089 ("powerpc/papr_scm: Add perf interface support")
>> Reported-by: Aneesh Kumar K.V
>> Signed-off-by: Kajol Jain
>> ---
>> arch/powerpc/platforms/pseries/papr_scm.c | 59 ++-
>> 1 file changed, 25 insertions(+), 34 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c
>> b/arch/powerpc/platforms/pseries/papr_scm.c
>> index 181b855b3050..5434c654a797 100644
>> --- a/arch/powerpc/platforms/pseries/papr_scm.c
>> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
>> @@ -350,6 +347,26 @@ static ssize_t drc_pmem_query_stats(struct
>> papr_scm_priv *p,
>> #ifdef CONFIG_PERF_EVENTS
>> #define to_nvdimm_pmu(_pmu) container_of(_pmu, struct nvdimm_pmu, pmu)
>>
>> +static const char * const nvdimm_events_map[] = {
>> +"N/A",
>> +"CtlResCt",
>> +"CtlResTm",
>> +"PonSecs ",
>> +"MemLife ",
>> +"CritRscU",
>> +"HostLCnt",
>> +"HostSCnt",
>> +"HostSDur",
>> +"HostLDur",
>> +"MedRCnt ",
>> +"MedWCnt ",
>> +"MedRDur ",
>> +"MedWDur ",
>> +"CchRHCnt",
>> +"CchWHCnt",
>> +"FastWCnt",
>> +};
>
> The order of the strings in that array becomes ABI. Because it defines
> the mapping from perf_event.attr.config (perf user ABI) to the actual
> event we request from the hypervisor.
>
> So I'd like that made more explicit by using designated initialisers, eg:
>
> static const char * const nvdimm_events_map[] = {
> [1] = "CtlResCt",
> [2] = "CtlResTm",
> ...
>
> That way an accidental reordering of the array won't break anything.
Yes make sense. Will do update it.
>
> You shouldn't need to specify 0 either as it's not used.
>
>> @@ -370,7 +387,7 @@ static int papr_scm_pmu_get_value(struct perf_event
>> *event, struct device *dev,
>>
>> stat = >scm_statistic[0];
>> memcpy(>stat_id,
>> - >nvdimm_events_map[event->attr.config *
>> sizeof(stat->stat_id)],
>> + nvdimm_events_map[event->attr.config],
>> sizeof(stat->stat_id));
>
> It's not clear that this won't index off the end of the array.
>
> There is a check in papr_scm_pmu_event_init(), but I'd probably be
> happier if we did an explicit check in here as well, eg:
>
> if (event->attr.config >= ARRAY_SIZE(nvdimm_events_map))
> return -EINVAL;
>
>
>> stat->stat_val = 0;
>>
>> @@ -460,10 +477,9 @@ static void papr_scm_pmu_del(struct perf_event *event,
>> int flags)
>>
>> static int papr_scm_pmu_check_events(struct papr_scm_priv *p, struct
>> nvdimm_pmu *nd_pmu)
>> {
>> -struct papr_scm_perf_stat *stat;
>> struct papr_scm_perf_stats *stats;
>> u32 available_events;
>> -int index, rc = 0;
>> +int rc = 0;
>
> You shouldn't need to initialise rc here. It's not used until the call
> to drc_pmem_query_stats() below.
Ok sure.
>
>> available_events = (p->stat_buffer_len - sizeof(struct
>> papr_scm_perf_stats))
>> / sizeof(struct papr_scm_perf_stat);
>> @@ -473,34 +489,12 @@ static int papr_scm_pmu_check_events(struct
>> papr_scm_priv *p, struct nvdimm_pmu
>> /* Allocate the buffer for phyp where stats are written */
>> stats = kzalloc(p->stat_buffer_len, GFP_KERNEL);
>> if (!stats) {
>> -rc = -ENOMEM;
>> -return rc;
>> +return -ENOMEM;
>> }
>>
Re: [PATCH V2] tools/perf/tests: Skip perf BPF test if clang is not present
On 5/11/22 17:24, Athira Rajeev wrote:
> Perf BPF filter test fails in environment where "clang"
> is not installed.
>
> Test failure logs:
>
> <<>>
> 42: BPF filter:
> 42.1: Basic BPF filtering : Skip
> 42.2: BPF pinning : FAILED!
> 42.3: BPF prologue generation : FAILED!
> <<>>
>
> Enabling verbose option provided debug logs which says
> clang/llvm needs to be installed. Snippet of verbose logs:
>
> <<>>
> 42.2: BPF pinning :
> --- start ---
> test child forked, pid 61423
> ERROR:unable to find clang.
> Hint: Try to install latest clang/llvm to support BPF.
> Check your $PATH
>
> <>
>
> Failed to compile test case: 'Basic BPF llvm compile'
> Unable to get BPF object, fix kbuild first
> test child finished with -1
> end
> BPF filter subtest 2: FAILED!
> <<>>
>
> Here subtests, "BPF pinning" and "BPF prologue generation"
> failed and logs shows clang/llvm is needed. After installing
> clang, testcase passes.
>
> Reason on why subtest failure happens though logs has proper
> debug information:
> Main function __test__bpf calls test_llvm__fetch_bpf_obj by
> passing 4th argument as true ( 4th arguments maps to parameter
> "force" in test_llvm__fetch_bpf_obj ). But this will cause
> test_llvm__fetch_bpf_obj to skip the check for clang/llvm.
>
> Snippet of code part which checks for clang based on
> parameter "force" in test_llvm__fetch_bpf_obj:
>
> <<>>
> if (!force && (!llvm_param.user_set_param &&
> <<>>
>
> Since force is set to "false", test won't get skipped and
> fails to compile test case. The BPF code compilation needs
> clang, So pass the fourth argument as "false" and also skip
> the test if reason for return is "TEST_SKIP"
>
> After the patch:
>
> <<>>
> 42: BPF filter:
> 42.1: Basic BPF filtering : Skip
> 42.2: BPF pinning : Skip
> 42.3: BPF prologue generation : Skip
> <<>>
>
> Fixes: ba1fae431e74 ("perf test: Add 'perf test BPF'")
> Signed-off-by: Athira Rajeev
> ---
> Changelog:
> Addressed review comments from Arnaldo by adding
> reason for skipping of testcase.
>
> tools/perf/tests/bpf.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
Patch looks fine to me.
Reviewed-by: Kajol Jain
Thanks,
Kajol Jain
>
> diff --git a/tools/perf/tests/bpf.c b/tools/perf/tests/bpf.c
> index 57b9591f7cbb..17c023823713 100644
> --- a/tools/perf/tests/bpf.c
> +++ b/tools/perf/tests/bpf.c
> @@ -222,11 +222,11 @@ static int __test__bpf(int idx)
>
> ret = test_llvm__fetch_bpf_obj(_buf, _buf_sz,
> bpf_testcase_table[idx].prog_id,
> -true, NULL);
> +false, NULL);
> if (ret != TEST_OK || !obj_buf || !obj_buf_sz) {
> pr_debug("Unable to get BPF object, %s\n",
>bpf_testcase_table[idx].msg_compile_fail);
> - if (idx == 0)
> + if ((idx == 0) || (ret == TEST_SKIP))
> return TEST_SKIP;
> else
> return TEST_FAIL;
> @@ -364,9 +364,11 @@ static int test__bpf_prologue_test(struct test_suite
> *test __maybe_unused,
> static struct test_case bpf_tests[] = {
> #ifdef HAVE_LIBBPF_SUPPORT
> TEST_CASE("Basic BPF filtering", basic_bpf_test),
> - TEST_CASE("BPF pinning", bpf_pinning),
> + TEST_CASE_REASON("BPF pinning", bpf_pinning,
> + "clang isn't installed or environment missing BPF
> support"),
> #ifdef HAVE_BPF_PROLOGUE
> - TEST_CASE("BPF prologue generation", bpf_prologue_test),
> + TEST_CASE_REASON("BPF prologue generation", bpf_prologue_test,
> + "clang isn't installed or environment missing BPF
> support"),
> #else
> TEST_CASE_REASON("BPF prologue generation", bpf_prologue_test, "not
> compiled in"),
> #endif
Re: [PATCH V2] tools/perf/tests: Fix session topology test to skip the test in guest environment
On 5/11/22 17:19, Athira Rajeev wrote:
> The session topology test fails in powerpc pSeries platform.
> Test logs:
> <<>>
> Session topology : FAILED!
> <<>>
>
> This testcases tests cpu topology by checking the core_id and
> socket_id stored in perf_env from perf session. The data from
> perf session is compared with the cpu topology information
> from "/sys/devices/system/cpu/cpuX/topology" like core_id,
> physical_package_id. In case of virtual environment, detail
> like physical_package_id is restricted to be exposed. Hence
> physical_package_id is set to -1. The testcase fails on such
> platforms since socket_id can't be fetched from topology info.
>
> Skip the testcase in powerpc if physical_package_id returns -1
>
Patch looks fine to me.
Reviewed-by: Kajol Jain
Thanks,
Kajol Jain
> Signed-off-by: Athira Rajeev
> ---
> Changelog:
> v1 -> v2:
> Addressed review comments from Arnaldo and Michael Ellerman.
> skip the test in powerpc when physical_package_id is set to
> -1.
> Dropped patch 1 from V1 since current change doesn't use info
> from /proc/cpuinfo and rather uses physical_package_id value.
>
> tools/perf/tests/topology.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/tools/perf/tests/topology.c b/tools/perf/tests/topology.c
> index ee1e3dcbc0bd..d23a9e322ff5 100644
> --- a/tools/perf/tests/topology.c
> +++ b/tools/perf/tests/topology.c
> @@ -109,6 +109,17 @@ static int check_cpu_topology(char *path, struct
> perf_cpu_map *map)
> && strncmp(session->header.env.arch, "aarch64", 7))
> return TEST_SKIP;
>
> + /*
> + * In powerpc pSeries platform, not all the topology information
> + * are exposed via sysfs. Due to restriction, detail like
> + * physical_package_id will be set to -1. Hence skip this
> + * test if physical_package_id returns -1 for cpu from perf_cpu_map.
> + */
> + if (strncmp(session->header.env.arch, "powerpc", 7)) {
> + if (cpu__get_socket_id(perf_cpu_map__cpu(map, 0)) == -1)
> + return TEST_SKIP;
> + }
> +
> TEST_ASSERT_VAL("Session header CPU map not set",
> session->header.env.cpu);
>
> for (i = 0; i < session->header.env.nr_cpus_avail; i++) {
Re: [PATCH V2 0/2] Fix session topology test for powerpc and add utility function to get cpuinfo entries
On 5/5/22 15:09, Athira Rajeev wrote: > The session topology test fails in powerpc pSeries platform. > Test logs: > <<>> > Session topology : FAILED! > <<>> > > This test uses cpu topology information and in powerpc, > some of the topology info is restricted in environment > like virtualized platform. Hence this test needs to be > skipped in pSeries platform for powerpc. The information > about platform is available in /proc/cpuinfo. > > Patch 1 adds generic utility function in "util/header.c" > to read /proc/cpuinfo for any entry. Though the testcase > fix needs value from "platform" entry, making this as a > generic function to return value for any entry from the > /proc/cpuinfo file which can be used commonly in future > usecases. > > Patch 2 uses the newly added utility function to look for > platform and skip the test in pSeries platform for powerpc. > > Athira Rajeev (2): > tools/perf: Add utility function to read /proc/cpuinfo for any field > tools/perf/tests: Fix session topology test to skip the test in guest > environment Hi Athira, Patchset looks good to me. Reviewed-by: Kajol Jain Thanks, Kajol Jain > > Changelog: > V1 -> v2: > Addressed review comments from Kajol. > Use "strim" to remove space from string. Also > use "feof" to check for EOF instead of using new > variable "ret". > > tools/perf/tests/topology.c | 17 > tools/perf/util/header.c| 53 + > tools/perf/util/header.h| 1 + > 3 files changed, 71 insertions(+) >
Re: [PATCH 1/2] tools/perf: Add utility function to read /proc/cpuinfo for any field
On 4/28/22 20:38, Athira Rajeev wrote:
> /proc/cpuinfo provides information about type of processor, number
> of CPU's etc. Reading /proc/cpuinfo file outputs useful information
> by field name like cpu, platform, model (depending on architecture)
> and its value separated by colon.
>
> Add new utility function "cpuinfo_field" in "util/header.c" which
> accepts field name as input string to search in /proc/cpuinfo content.
> This returns the first matching value as resulting string. Example,
> calling the function "cpuinfo_field(platform)" in powerpc returns
> the platform value. This can be used to fetch processor information
> from "cpuinfo" by other utilities/testcases.
>
> Signed-off-by: Athira Rajeev
> ---
> tools/perf/util/header.c | 54
> tools/perf/util/header.h | 1 +
> 2 files changed, 55 insertions(+)
>
> diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
> index a27132e5a5ef..0c8dfd0c1e78 100644
> --- a/tools/perf/util/header.c
> +++ b/tools/perf/util/header.c
> @@ -983,6 +983,60 @@ static int write_dir_format(struct feat_fd *ff,
> return do_write(ff, >dir.version, sizeof(data->dir.version));
> }
>
> +/*
> + * Return entry from /proc/cpuinfo
> + * indicated by "search" parameter.
> + */
> +char *cpuinfo_field(const char *search)
> +{
> + FILE *file;
> + char *buf = NULL;
> + char *copy_buf = NULL, *p;
> + size_t len = 0;
> + int ret = -1;
> +
> + if (!search)
> + return NULL;
> +
> + file = fopen("/proc/cpuinfo", "r");
> + if (!file)
> + return NULL;
> +
> + while (getline(, , file) > 0) {
> + ret = strncmp(buf, search, strlen(search));
> + if (!ret)
> + break;
Hi Athira,
Do we need ret variable. Since we will come out of the loop only when
we reach EOF.
> + }
> +
> + if (ret)
> + goto done;
> +
> + /*
> + * Trim the new line and separate
> + * value for search field from ":"
> + * in cpuinfo line output.
> + * Example output line:
> + * platform :
> + */
> + copy_buf = buf;
> + p = strchr(copy_buf, ':');
> + if (p && *(p+1) == ' ' && *(p+2))
Can you try using strim instead to remove whitespaces. This function
will remove leading and trailing whitespaces from the string.
> + copy_buf = p + 2;
> + p = strchr(copy_buf, '\n');
do we need to replace `\n` here ?
> + if (p)
> + *p = '\0';
> +
> + /* Copy the filtered string to buf */
> + strcpy(buf, copy_buf)
You are initializing buf to NULL. So do we need to do fclose and return
buf separately here? Can you move free(buf) in above condition and reuse
`done` code.
> +
> + fclose(file);
> + return buf;> +
> +done:
> + free(buf);
> + fclose(file);
> + return NULL;
> +}
> /*
> * Check whether a CPU is online
> *
> diff --git a/tools/perf/util/header.h b/tools/perf/util/header.h
> index 0eb4bc29a5a4..b0f754364bd4 100644
> --- a/tools/perf/util/header.h
> +++ b/tools/perf/util/header.h
> @@ -166,4 +166,5 @@ int get_cpuid(char *buffer, size_t sz);
>
> char *get_cpuid_str(struct perf_pmu *pmu __maybe_unused);
> int strcmp_cpuid_str(const char *s1, const char *s2);
> +char *cpuinfo_field(const char *search);
> #endif /* __PERF_HEADER_H */
Re: [PATCH] selftests/powerpc/pmu: Fix unsigned function returning negative constant
On 4/24/22 13:56, Haowen Bai wrote:
> The function __perf_reg_mask has an unsigned return type, but returns a
> negative constant to indicate an error condition. So we change unsigned
> to int.
>
> Signed-off-by: Haowen Bai
> ---
> tools/testing/selftests/powerpc/pmu/sampling_tests/misc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/powerpc/pmu/sampling_tests/misc.c
> b/tools/testing/selftests/powerpc/pmu/sampling_tests/misc.c
> index fca054bbc094..c01a31d5f4ee 100644
> --- a/tools/testing/selftests/powerpc/pmu/sampling_tests/misc.c
> +++ b/tools/testing/selftests/powerpc/pmu/sampling_tests/misc.c
> @@ -274,7 +274,7 @@ u64 *get_intr_regs(struct event *event, void *sample_buff)
> return intr_regs;
> }
>
> -static const unsigned int __perf_reg_mask(const char *register_name)
> +static const int __perf_reg_mask(const char *register_name)
> {
Hi Haowen,
Thanks for correcting it. Can you also add fix tag with corresponding
commit id details.
Other than that patch looks good to me.
Reviewed-by: Kajol Jain
Thanks,
Kajol Jain
> if (!strcmp(register_name, "R0"))
> return 0;
Re: [PATCH 1/2] drivers/nvdimm: Fix build failure when CONFIG_PERF_EVENTS is not set
On 3/22/22 07:40, Dan Williams wrote:
> On Fri, Mar 18, 2022 at 4:42 AM Kajol Jain wrote:
>>
>> The following build failure occures when CONFIG_PERF_EVENTS is not set
>> as generic pmu functions are not visible in that scenario.
>>
>> |-- s390-randconfig-r044-20220313
>> | |-- nd_perf.c:(.text):undefined-reference-to-perf_pmu_migrate_context
>> | |-- nd_perf.c:(.text):undefined-reference-to-perf_pmu_register
>> | `-- nd_perf.c:(.text):undefined-reference-to-perf_pmu_unregister
>>
>> Similar build failure in nds32 architecture:
>> nd_perf.c:(.text+0x21e): undefined reference to `perf_pmu_migrate_context'
>> nd_perf.c:(.text+0x434): undefined reference to `perf_pmu_register'
>> nd_perf.c:(.text+0x57c): undefined reference to `perf_pmu_unregister'
>>
>> Fix this issue by adding check for CONFIG_PERF_EVENTS config option
>> and disabling the nvdimm perf interface incase this config is not set.
>>
>> Also removed function declaration of perf_pmu_migrate_context,
>> perf_pmu_register, perf_pmu_unregister functions from nd.h as these are
>> common pmu functions which are part of perf_event.h and since we
>> are disabling nvdimm perf interface incase CONFIG_PERF_EVENTS option
>> is not set, we not need to declare them in nd.h
>>
>> Fixes: 0fab1ba6ad6b ("drivers/nvdimm: Add perf interface to expose
>> nvdimm performance stats") (Commit id based on linux-next tree)
>> Signed-off-by: Kajol Jain
>> Link:
>> https://lore.kernel.org/all/62317124.ybqfu33+s%2fwdvwgj%25...@intel.com/
>> Reported-by: kernel test robot
>> ---
>> drivers/nvdimm/Makefile | 2 +-
>> include/linux/nd.h | 7 ---
>> 2 files changed, 5 insertions(+), 4 deletions(-)
>>
>> ---
>> - This fix patch changes are added and tested on top of linux-next tree
>> on the 'next-20220315' branch.
>> ---
>> diff --git a/drivers/nvdimm/Makefile b/drivers/nvdimm/Makefile
>> index 3fb806748716..ba0296dca9db 100644
>> --- a/drivers/nvdimm/Makefile
>> +++ b/drivers/nvdimm/Makefile
>> @@ -15,7 +15,7 @@ nd_e820-y := e820.o
>> libnvdimm-y := core.o
>> libnvdimm-y += bus.o
>> libnvdimm-y += dimm_devs.o
>> -libnvdimm-y += nd_perf.o
>> +libnvdimm-$(CONFIG_PERF_EVENTS) += nd_perf.o
>> libnvdimm-y += dimm.o
>> libnvdimm-y += region_devs.o
>> libnvdimm-y += region.o
>> diff --git a/include/linux/nd.h b/include/linux/nd.h
>> index 7b2ccbdc1cbc..a4265eaf5ae8 100644
>> --- a/include/linux/nd.h
>> +++ b/include/linux/nd.h
>> @@ -8,8 +8,10 @@
>> #include
>> #include
>> #include
>> +#ifdef CONFIG_PERF_EVENTS
>> #include
>
> Why must this not be included? Doesn't it already handle the
> CONFIG_PERF_EVENTS=n case internally?
>
>> #include
>
> I notice now that this platform-device header should have never been
> added in the first place, just forward declare:
>
> struct platform_device;
Hi Dan,
Sure I will do the required changes.
Thanks,
Kajol Jain
>
>> +#endif
>>
>> enum nvdimm_event {
>> NVDIMM_REVALIDATE_POISON,
>> @@ -25,6 +27,7 @@ enum nvdimm_claim_class {
>> NVDIMM_CCLASS_UNKNOWN,
>> };
>>
>> +#ifdef CONFIG_PERF_EVENTS
>> #define NVDIMM_EVENT_VAR(_id) event_attr_##_id
>> #define NVDIMM_EVENT_PTR(_id) (_attr_##_id.attr.attr)
>
> Why must these be inside the ifdef guard?
>
>>
>> @@ -63,9 +66,7 @@ extern ssize_t nvdimm_events_sysfs_show(struct device *dev,
>>
>> int register_nvdimm_pmu(struct nvdimm_pmu *nvdimm, struct platform_device
>> *pdev);
>> void unregister_nvdimm_pmu(struct nvdimm_pmu *nd_pmu);
>
> Shouldn't there also be stub functions in the CONFIG_PERF_EVENTS=n case?
>
> static inline int register_nvdimm_pmu(struct nvdimm_pmu *nvdimm,
> struct platform_device *pdev)
> {
> return -ENXIO;
> }
>
> static inline void unregister_nvdimm_pmu(struct nvdimm_pmu *nd_pmu)
> {
> }
>
>> -void perf_pmu_migrate_context(struct pmu *pmu, int src_cpu, int dst_cpu);
>> -int perf_pmu_register(struct pmu *pmu, const char *name, int type);
>> -void perf_pmu_unregister(struct pmu *pmu);
>
> Yeah, I should have caught these earlier.
>
>> +#endif
>>
>> struct nd_device_driver {
>> struct device_driver drv;
>> --
>> 2.31.1
>>
Re: [PATCH 2/2] powerpc/papr_scm: Fix build failure when CONFIG_PERF_EVENTS is not set
On 3/23/22 21:02, Dan Williams wrote:
> On Wed, Mar 23, 2022 at 3:05 AM Michael Ellerman wrote:
>>
>> Dan Williams writes:
>>> On Tue, Mar 22, 2022 at 7:30 AM kajoljain wrote:
>>>> On 3/22/22 03:09, Dan Williams wrote:
>>>>> On Fri, Mar 18, 2022 at 4:42 AM Kajol Jain wrote:
>>>>>>
>>>>>> The following build failure occures when CONFIG_PERF_EVENTS is not set
>>>>>> as generic pmu functions are not visible in that scenario.
>>>>>>
>>>>>> arch/powerpc/platforms/pseries/papr_scm.c:372:35: error: ‘struct
>>>>>> perf_event’ has no member named ‘attr’
>>>>>> p->nvdimm_events_map[event->attr.config],
>>>>>>^~
>>>>>> In file included from ./include/linux/list.h:5,
>>>>>> from ./include/linux/kobject.h:19,
>>>>>> from ./include/linux/of.h:17,
>>>>>> from arch/powerpc/platforms/pseries/papr_scm.c:5:
>>>>>> arch/powerpc/platforms/pseries/papr_scm.c: In function
>>>>>> ‘papr_scm_pmu_event_init’:
>>>>>> arch/powerpc/platforms/pseries/papr_scm.c:389:49: error: ‘struct
>>>>>> perf_event’ has no member named ‘pmu’
>>>>>> struct nvdimm_pmu *nd_pmu = to_nvdimm_pmu(event->pmu);
>>>>>> ^~
>>>>>> ./include/linux/container_of.h:18:26: note: in definition of macro
>>>>>> ‘container_of’
>>>>>> void *__mptr = (void *)(ptr); \
>>>>>> ^~~
>>>>>> arch/powerpc/platforms/pseries/papr_scm.c:389:30: note: in expansion of
>>>>>> macro ‘to_nvdimm_pmu’
>>>>>> struct nvdimm_pmu *nd_pmu = to_nvdimm_pmu(event->pmu);
>>>>>> ^
>>>>>> In file included from ./include/linux/bits.h:22,
>>>>>> from ./include/linux/bitops.h:6,
>>>>>> from ./include/linux/of.h:15,
>>>>>> from arch/powerpc/platforms/pseries/papr_scm.c:5:
>>>>>>
>>>>>> Fix the build issue by adding check for CONFIG_PERF_EVENTS config option
>>>>>> and disabling the papr_scm perf interface support incase this config
>>>>>> is not set
>>>>>>
>>>>>> Fixes: 4c08d4bbc089 ("powerpc/papr_scm: Add perf interface support")
>>>>>> (Commit id
>>>>>> based on linux-next tree)
>>>>>> Signed-off-by: Kajol Jain
>>>>>> ---
>>>>>> arch/powerpc/platforms/pseries/papr_scm.c | 15 +++
>>>>>
>>>>> This is a bit messier than I would have liked mainly because it dumps
>>>>> a bunch of ifdefery into a C file contrary to coding style, "Wherever
>>>>> possible, don't use preprocessor conditionals (#if, #ifdef) in .c
>>>>> files". I would expect this all to move to an organization like:
>>>>
>>>> Hi Dan,
>>>> Thanks for reviewing the patches. Inorder to avoid the multiple
>>>> ifdefs checks, we can also add stub function for papr_scm_pmu_register.
>>>> With that change we will just have one ifdef check for
>>>> CONFIG_PERF_EVENTS config in both papr_scm.c and nd.h file. Hence we can
>>>> avoid adding new files specific for papr_scm perf interface.
>>>>
>>>> Below is the code snippet for that change, let me know if looks fine to
>>>> you. I tested it
>>>> with set/unset PAPR_SCM config value and set/unset PERF_EVENTS config
>>>> value combinations.
>>>>
>>>> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c
>>>> b/arch/powerpc/platforms/pseries/papr_scm.c
>>>> index 4dd513d7c029..38fabb44d3c3 100644
>>>> --- a/arch/powerpc/platforms/pseries/papr_scm.c
>>>> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
>>>> @@ -69,8 +69,6 @@
>>>> #define PAPR_SCM_PERF_STATS_EYECATCHER __stringify(SCMSTATS)
>>>> #define PAPR_SCM_PERF_STATS_VERSION 0x1
>>>>
>>>> -#define to_nvdimm_pmu(_pmu)container_of(_pmu, struct nvdimm_pmu, pmu)
>>>> -
>>>> /* Struct holding a single performance metric */
>>>> struct papr_scm_perf_stat {
Re: [PATCH 2/2] powerpc/papr_scm: Fix build failure when CONFIG_PERF_EVENTS is not set
On 3/22/22 07:15, Dan Williams wrote:
> On Mon, Mar 21, 2022 at 2:39 PM Dan Williams wrote:
>>
>> On Fri, Mar 18, 2022 at 4:42 AM Kajol Jain wrote:
>>>
>>> The following build failure occures when CONFIG_PERF_EVENTS is not set
>>> as generic pmu functions are not visible in that scenario.
>>>
>>> arch/powerpc/platforms/pseries/papr_scm.c:372:35: error: ‘struct
>>> perf_event’ has no member named ‘attr’
>>> p->nvdimm_events_map[event->attr.config],
>>>^~
>>> In file included from ./include/linux/list.h:5,
>>> from ./include/linux/kobject.h:19,
>>> from ./include/linux/of.h:17,
>>> from arch/powerpc/platforms/pseries/papr_scm.c:5:
>>> arch/powerpc/platforms/pseries/papr_scm.c: In function
>>> ‘papr_scm_pmu_event_init’:
>>> arch/powerpc/platforms/pseries/papr_scm.c:389:49: error: ‘struct
>>> perf_event’ has no member named ‘pmu’
>>> struct nvdimm_pmu *nd_pmu = to_nvdimm_pmu(event->pmu);
>>> ^~
>>> ./include/linux/container_of.h:18:26: note: in definition of macro
>>> ‘container_of’
>>> void *__mptr = (void *)(ptr); \
>>> ^~~
>>> arch/powerpc/platforms/pseries/papr_scm.c:389:30: note: in expansion of
>>> macro ‘to_nvdimm_pmu’
>>> struct nvdimm_pmu *nd_pmu = to_nvdimm_pmu(event->pmu);
>>> ^
>>> In file included from ./include/linux/bits.h:22,
>>> from ./include/linux/bitops.h:6,
>>> from ./include/linux/of.h:15,
>>> from arch/powerpc/platforms/pseries/papr_scm.c:5:
>>>
>>> Fix the build issue by adding check for CONFIG_PERF_EVENTS config option
>>> and disabling the papr_scm perf interface support incase this config
>>> is not set
>>>
>>> Fixes: 4c08d4bbc089 ("powerpc/papr_scm: Add perf interface support")
>>> (Commit id
>>> based on linux-next tree)
>>> Signed-off-by: Kajol Jain
>>> ---
>>> arch/powerpc/platforms/pseries/papr_scm.c | 15 +++
>>
>> This is a bit messier than I would have liked mainly because it dumps
>> a bunch of ifdefery into a C file contrary to coding style, "Wherever
>> possible, don't use preprocessor conditionals (#if, #ifdef) in .c
>> files". I would expect this all to move to an organization like:
>>
>> arch/powerpc/platforms/pseries/papr_scm/main.c
>> arch/powerpc/platforms/pseries/papr_scm/perf.c
>>
>> ...and a new config symbol like:
>>
>> config PAPR_SCM_PERF
>>depends on PAPR_SCM && PERF_EVENTS
>>def_bool y
>>
>> ...with wrappers in header files to make everything compile away
>> without any need for main.c to carry an ifdef.
>>
>> Can you turn a patch like that in the next couple days? Otherwise, I
>> think if Linus saw me sending a late breaking compile fix that threw
>> coding style out the window he'd have cause to just drop the pull
>> request entirely.
>
> Also, please base it on the current state of the libnvdimm-for-next
> branch as -next includes some of the SMART health changes leading to
> at least one conflict.
Ok Dan, I will rebase my changes on top of libnvdimm-for-next branch.
Thanks,
Kajol Jain
Re: [PATCH 2/2] powerpc/papr_scm: Fix build failure when CONFIG_PERF_EVENTS is not set
On 3/22/22 03:09, Dan Williams wrote:
> On Fri, Mar 18, 2022 at 4:42 AM Kajol Jain wrote:
>>
>> The following build failure occures when CONFIG_PERF_EVENTS is not set
>> as generic pmu functions are not visible in that scenario.
>>
>> arch/powerpc/platforms/pseries/papr_scm.c:372:35: error: ‘struct perf_event’
>> has no member named ‘attr’
>> p->nvdimm_events_map[event->attr.config],
>>^~
>> In file included from ./include/linux/list.h:5,
>> from ./include/linux/kobject.h:19,
>> from ./include/linux/of.h:17,
>> from arch/powerpc/platforms/pseries/papr_scm.c:5:
>> arch/powerpc/platforms/pseries/papr_scm.c: In function
>> ‘papr_scm_pmu_event_init’:
>> arch/powerpc/platforms/pseries/papr_scm.c:389:49: error: ‘struct perf_event’
>> has no member named ‘pmu’
>> struct nvdimm_pmu *nd_pmu = to_nvdimm_pmu(event->pmu);
>> ^~
>> ./include/linux/container_of.h:18:26: note: in definition of macro
>> ‘container_of’
>> void *__mptr = (void *)(ptr); \
>> ^~~
>> arch/powerpc/platforms/pseries/papr_scm.c:389:30: note: in expansion of
>> macro ‘to_nvdimm_pmu’
>> struct nvdimm_pmu *nd_pmu = to_nvdimm_pmu(event->pmu);
>> ^
>> In file included from ./include/linux/bits.h:22,
>> from ./include/linux/bitops.h:6,
>> from ./include/linux/of.h:15,
>> from arch/powerpc/platforms/pseries/papr_scm.c:5:
>>
>> Fix the build issue by adding check for CONFIG_PERF_EVENTS config option
>> and disabling the papr_scm perf interface support incase this config
>> is not set
>>
>> Fixes: 4c08d4bbc089 ("powerpc/papr_scm: Add perf interface support") (Commit
>> id
>> based on linux-next tree)
>> Signed-off-by: Kajol Jain
>> ---
>> arch/powerpc/platforms/pseries/papr_scm.c | 15 +++
>
> This is a bit messier than I would have liked mainly because it dumps
> a bunch of ifdefery into a C file contrary to coding style, "Wherever
> possible, don't use preprocessor conditionals (#if, #ifdef) in .c
> files". I would expect this all to move to an organization like:
Hi Dan,
Thanks for reviewing the patches. Inorder to avoid the multiple
ifdefs checks, we can also add stub function for papr_scm_pmu_register.
With that change we will just have one ifdef check for
CONFIG_PERF_EVENTS config in both papr_scm.c and nd.h file. Hence we can
avoid adding new files specific for papr_scm perf interface.
Below is the code snippet for that change, let me know if looks fine to
you. I tested it
with set/unset PAPR_SCM config value and set/unset PERF_EVENTS config
value combinations.
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c
b/arch/powerpc/platforms/pseries/papr_scm.c
index 4dd513d7c029..38fabb44d3c3 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -69,8 +69,6 @@
#define PAPR_SCM_PERF_STATS_EYECATCHER __stringify(SCMSTATS)
#define PAPR_SCM_PERF_STATS_VERSION 0x1
-#define to_nvdimm_pmu(_pmu)container_of(_pmu, struct nvdimm_pmu, pmu)
-
/* Struct holding a single performance metric */
struct papr_scm_perf_stat {
u8 stat_id[8];
@@ -346,6 +344,9 @@ static ssize_t drc_pmem_query_stats(struct
papr_scm_priv *p,
return 0;
}
+#ifdef CONFIG_PERF_EVENTS
+#define to_nvdimm_pmu(_pmu)container_of(_pmu, struct nvdimm_pmu, pmu)
+
static int papr_scm_pmu_get_value(struct perf_event *event, struct
device *dev, u64 *count)
{
struct papr_scm_perf_stat *stat;
@@ -558,6 +559,10 @@ static void papr_scm_pmu_register(struct
papr_scm_priv *p)
dev_info(>pdev->dev, "nvdimm pmu didn't register rc=%d\n", rc);
}
+#else
+static inline void papr_scm_pmu_register(struct papr_scm_priv *p) { }
+#endif
+
/*
* Issue hcall to retrieve dimm health info and populate papr_scm_priv
with the
* health information.
diff --git a/drivers/nvdimm/Makefile b/drivers/nvdimm/Makefile
index 3fb806748716..ba0296dca9db 100644
--- a/drivers/nvdimm/Makefile
+++ b/drivers/nvdimm/Makefile
@@ -15,7 +15,7 @@ nd_e820-y := e820.o
libnvdimm-y := core.o
libnvdimm-y += bus.o
libnvdimm-y += dimm_devs.o
-libnvdimm-y += nd_perf.o
+libnvdimm-$(CONFIG_PERF_EVENTS) += nd_perf.o
libnvdimm-y += dimm.o
libnvdimm-y += region_devs.o
libnvdimm-y += region.o
diff --git a/include/linux/nd.h b/include/linux/nd.h
index 7b2ccbdc1cbc..a387e2b630ad 100644
--- a/include/linux/nd.h
+++ b/include/linux/nd.h
@@ -57,15 +57,22 @@ struct nvdimm_pmu {
struct cpumask arch_cpumask;
};
+#ifdef CONFIG_PERF_EVENTS
extern ssize_t nvdimm_events_sysfs_show(struct device *dev,
struct device_attribute *attr,
char *page);
int register_nvdimm_pmu(struct nvdimm_pmu *nvdimm, struct
platform_device *pdev);
void unregister_nvdimm_pmu(struct nvdimm_pmu
Re: linux-next: manual merge of the nvdimm tree with the powerpc tree
On 3/15/22 13:45, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the nvdimm tree got a conflict in:
>
> arch/powerpc/platforms/pseries/papr_scm.c
>
> between commit:
>
> bbbca72352bb ("powerpc/papr_scm: Implement initial support for injecting
> smart errors")
>
> from the powerpc tree and commit:
>
> 4c08d4bbc089 ("powerpc/papr_scm: Add perf interface support")
>
> from the nvdimm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
Hi Stephan,
The change for resolving merged trees issue looks good to me. I
also tested the latest linux-next tree - master branch with
next-20220315 changes and the papr_scm perf interface is working as
expected. Thanks for correcting it.
Thanks,
Kajol Jain
Re: [PATCH 16/20] selftest/powerpc/pmu/: Add selftest for mmcr1 pmcxsel/unit/cache fields
On 3/10/22 17:41, Michael Ellerman wrote: > Christophe Leroy writes: >> Le 27/01/2022 à 08:20, Kajol Jain a écrit : >>> From: Athira Rajeev >>> >>> The testcase uses event code "0x134001c040" to verify >>> the settings for different fields in Monitor Mode Control >>> Register 1 (MMCR1). The fields include PMCxSEL, PMCXCOMB >>> PMCxUNIT, cache. Checks if these fields are translated >>> correctly via perf interface to MMCR1 >>> >>> Signed-off-by: Athira Rajeev >> >> I see the series has been accepted but this patch has been left over. >> >> Any reason ? > > Yeah it's flakey. It counts cache loads but the workload it runs doesn't > necessarily cause any, so it sometimes fails. I've reported that > privately to Kajol. > Hi Christophe, As Michael mentioned, with the current workload we used in this patch, the testcase was failing sometimes as required cache load not happening everytime. We will send this patch separately with proper workload in next version. Thanks, Kajol Jain > cheers
Re: [PATCH v7 0/4] Add perf interface to expose nvdimm
Hi Dan, Can you take this patch-set if it looks fine to you. Thanks, Kajol Jain On 2/25/22 20:00, Kajol Jain wrote: > Patchset adds performance stats reporting support for nvdimm. > Added interface includes support for pmu register/unregister > functions. A structure is added called nvdimm_pmu to be used for > adding arch/platform specific data such as cpumask, nvdimm device > pointer and pmu event functions like event_init/add/read/del. > User could use the standard perf tool to access perf events > exposed via pmu. > > Interface also defines supported event list, config fields for the > event attributes and their corresponding bit values which are exported > via sysfs. Patch 3 exposes IBM pseries platform nmem* device > performance stats using this interface. > > Result from power9 pseries lpar with 2 nvdimm device: > > Ex: List all event by perf list > > command:# perf list nmem > > nmem0/cache_rh_cnt/[Kernel PMU event] > nmem0/cache_wh_cnt/[Kernel PMU event] > nmem0/cri_res_util/[Kernel PMU event] > nmem0/ctl_res_cnt/ [Kernel PMU event] > nmem0/ctl_res_tm/ [Kernel PMU event] > nmem0/fast_w_cnt/ [Kernel PMU event] > nmem0/host_l_cnt/ [Kernel PMU event] > nmem0/host_l_dur/ [Kernel PMU event] > nmem0/host_s_cnt/ [Kernel PMU event] > nmem0/host_s_dur/ [Kernel PMU event] > nmem0/med_r_cnt/ [Kernel PMU event] > nmem0/med_r_dur/ [Kernel PMU event] > nmem0/med_w_cnt/ [Kernel PMU event] > nmem0/med_w_dur/ [Kernel PMU event] > nmem0/mem_life/[Kernel PMU event] > nmem0/poweron_secs/[Kernel PMU event] > ... > nmem1/mem_life/[Kernel PMU event] > nmem1/poweron_secs/[Kernel PMU event] > > Patch1: > Introduces the nvdimm_pmu structure > Patch2: > Adds common interface to add arch/platform specific data > includes nvdimm device pointer, pmu data along with > pmu event functions. It also defines supported event list > and adds attribute groups for format, events and cpumask. > It also adds code for cpu hotplug support. > Patch3: > Add code in arch/powerpc/platform/pseries/papr_scm.c to expose > nmem* pmu. It fills in the nvdimm_pmu structure with pmu name, > capabilities, cpumask and event functions and then registers > the pmu by adding callbacks to register_nvdimm_pmu. > Patch4: > Sysfs documentation patch > > Changelog > --- > v6 -> v7 > - Add function call to numa_map_to_online_node function inorder to > get online numa node. As the node id returned by function dev_to_node > can be offline in some scenarios and can create issue in hotplug code > as reported by Nageswara R Sastry. > > - Add function declaration of perf_pmu_register, perf_pmu_unregister > and perf_pmu_migrate_context functions in nd.h file to resolve > the implicit-function-declaration warning as reported by kernel test > robot. > Link: https://lore.kernel.org/all/202202241242.zqzgkguy-...@intel.com/ > > - Add Tested-by, Acked-by and Reported-by tags from Peter Zijlstra > and Nageswara R Sastry. > > - Link to the patchset v6: https://lkml.org/lkml/2022/2/17/857 > > Resend v5 -> v6 > - No logic change, just a rebase to latest upstream and > tested the patchset. > > - Link to the patchset Resend v5: https://lkml.org/lkml/2021/11/15/3979 > > v5 -> Resend v5 > - Resend the patchset > > - Link to the patchset v5: https://lkml.org/lkml/2021/9/28/643 > > v4 -> v5: > - Remove multiple variables defined in nvdimm_pmu structure include > name and pmu functions(event_int/add/del/read) as they are just > used to copy them again in pmu variable. Now we are directly doing > this step in arch specific code as suggested by Dan Williams. > > - Remove attribute group field from nvdimm pmu structure and > defined these attribute groups in common interface which > includes format, event list along with cpumask as suggested by > Dan Williams. > Since we added static defination for attrbute groups needed in > common interface, removes corresponding code from papr. > > - Add nvdimm pmu event list with event codes in the common interface. > > - Remove Acked-by/Reviewed-by/Tested-by tags as code is refactored > to handle review comments from Dan. > > - Make nvdimm_pmu_free_hotplug_memory function static as reported > by kernel test robot, also add corresponding Reported-by tag. > > - Link to the
Re: [PATCH v6 0/4] Add perf interface to expose nvdimm
On 2/25/22 16:41, Nageswara Sastry wrote: > > > On 25/02/22 12:08 pm, kajoljain wrote: >> >> >> On 2/25/22 11:25, Nageswara Sastry wrote: >>> >>> >>> On 17/02/22 10:03 pm, Kajol Jain wrote: >>>> Patchset adds performance stats reporting support for nvdimm. >>>> Added interface includes support for pmu register/unregister >>>> functions. A structure is added called nvdimm_pmu to be used for >>>> adding arch/platform specific data such as cpumask, nvdimm device >>>> pointer and pmu event functions like event_init/add/read/del. >>>> User could use the standard perf tool to access perf events >>>> exposed via pmu. >>>> >>>> Interface also defines supported event list, config fields for the >>>> event attributes and their corresponding bit values which are exported >>>> via sysfs. Patch 3 exposes IBM pseries platform nmem* device >>>> performance stats using this interface. >>>> >>>> Result from power9 pseries lpar with 2 nvdimm device: >>>> >>>> Ex: List all event by perf list >>>> >>>> command:# perf list nmem >>>> >>>> nmem0/cache_rh_cnt/ [Kernel PMU >>>> event] >>>> nmem0/cache_wh_cnt/ [Kernel PMU >>>> event] >>>> nmem0/cri_res_util/ [Kernel PMU >>>> event] >>>> nmem0/ctl_res_cnt/ [Kernel PMU >>>> event] >>>> nmem0/ctl_res_tm/ [Kernel PMU >>>> event] >>>> nmem0/fast_w_cnt/ [Kernel PMU >>>> event] >>>> nmem0/host_l_cnt/ [Kernel PMU >>>> event] >>>> nmem0/host_l_dur/ [Kernel PMU >>>> event] >>>> nmem0/host_s_cnt/ [Kernel PMU >>>> event] >>>> nmem0/host_s_dur/ [Kernel PMU >>>> event] >>>> nmem0/med_r_cnt/ [Kernel PMU >>>> event] >>>> nmem0/med_r_dur/ [Kernel PMU >>>> event] >>>> nmem0/med_w_cnt/ [Kernel PMU >>>> event] >>>> nmem0/med_w_dur/ [Kernel PMU >>>> event] >>>> nmem0/mem_life/ [Kernel PMU >>>> event] >>>> nmem0/poweron_secs/ [Kernel PMU >>>> event] >>>> ... >>>> nmem1/mem_life/ [Kernel PMU >>>> event] >>>> nmem1/poweron_secs/ [Kernel PMU >>>> event] >>>> >>>> Patch1: >>>> Introduces the nvdimm_pmu structure >>>> Patch2: >>>> Adds common interface to add arch/platform specific data >>>> includes nvdimm device pointer, pmu data along with >>>> pmu event functions. It also defines supported event list >>>> and adds attribute groups for format, events and cpumask. >>>> It also adds code for cpu hotplug support. >>>> Patch3: >>>> Add code in arch/powerpc/platform/pseries/papr_scm.c to >>>> expose >>>> nmem* pmu. It fills in the nvdimm_pmu structure with pmu >>>> name, >>>> capabilities, cpumask and event functions and then registers >>>> the pmu by adding callbacks to register_nvdimm_pmu. >>>> Patch4: >>>> Sysfs documentation patch >>>> >>>> Changelog >>> >>> Tested these patches with the automated tests at >>> avocado-misc-tests/perf/perf_nmem.py >>> URL: >>> https://github.com/avocado-framework-tests/avocado-misc-tests/blob/master/perf/perf_nmem.py >>> >>> >>> >>> 1. On the system where target id and online id were different then not >>> seeing value in 'cpumask' and those tests failed. >>> >>> Example: >>> Log from dmesg >>> ... >>> papr_scm ibm,persistent-memory:ibm,pmemory@4413: Region registered >>> with target node 1 and online node 0 >
Re: [PATCH v6 0/4] Add perf interface to expose nvdimm
On 2/25/22 13:17, Aneesh Kumar K V wrote: > On Fri, 2022-02-25 at 12:08 +0530, kajoljain wrote: >> >> >> On 2/25/22 11:25, Nageswara Sastry wrote: >>> >>> >>> On 17/02/22 10:03 pm, Kajol Jain wrote: >>>> > >>>> >>>> Changelog >>> >>> Tested these patches with the automated tests at >>> avocado-misc-tests/perf/perf_nmem.py >>> URL: >>> https://github.com/avocado-framework-tests/avocado-misc-tests/blob/master/perf/perf_nmem.py >>> >>> >>> 1. On the system where target id and online id were different then >>> not >>> seeing value in 'cpumask' and those tests failed. >>> >>> Example: >>> Log from dmesg >>> ... >>> papr_scm ibm,persistent-memory:ibm,pmemory@4413: Region >>> registered >>> with target node 1 and online node 0 >>> ... >> >> Hi Nageswara Sastry, >> Thanks for testing the patch set. Yes you right, incase target >> node id and online node id is different, it can happen when target >> node is not online and hence can cause this issue, thanks for >> pointing >> it. >> >> Function dev_to_node will return node id for a given nvdimm device >> which >> can be offline in some scenarios. We should use numa node id return >> by >> numa_map_to_online_node function in that scenario. This function >> incase >> given node is offline, it will lookup for next closest online node >> and >> return that nodeid. >> >> Can you try with below change and see, if you are still getting this >> issue. Please let me know. >> >> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c >> b/arch/powerpc/platforms/pseries/papr_scm.c >> index bdf2620db461..4dd513d7c029 100644 >> --- a/arch/powerpc/platforms/pseries/papr_scm.c >> +++ b/arch/powerpc/platforms/pseries/papr_scm.c >> @@ -536,7 +536,7 @@ static void papr_scm_pmu_register(struct >> papr_scm_priv *p) >> PERF_PMU_CAP_NO_EXCLUDE; >> >> /*updating the cpumask variable */ >> - nodeid = dev_to_node(>pdev->dev); >> + nodeid = numa_map_to_online_node(dev_to_node(>pdev->dev)); >> nd_pmu->arch_cpumask = *cpumask_of_node(nodeid); >> >>> > > Can you use p->region->numa_node? Hi Aneesh, Thanks for reviewing the changes. Actually we can't use numa_node field of region structure directly inside papr_scm.c as we will get dereferencing issue Result of build with this change: arch/powerpc/platforms/pseries/papr_scm.c: In function 'papr_scm_pmu_register': arch/powerpc/platforms/pseries/papr_scm.c:539:21: error: dereferencing pointer to incomplete type 'struct nd_region' nodeid = >region->numa_node; ^~ make[3]: *** [scripts/Makefile.build:288: arch/powerpc/platforms/pseries/papr_scm.o] Error 1 make[2]: *** [scripts/Makefile.build:550: arch/powerpc/platforms/pseries] Erro This is because, this structure is defined inside drivers/nvdimm/nd.h code which is not included in this file. So, thats why I am using `numa_map_to_online_node(dev_to_node(>pdev->dev));` directly. Let me know if you are ok with initial change. Thanks, Kajol Jain > > -aneesh > >
Re: [PATCH v6 0/4] Add perf interface to expose nvdimm
On 2/25/22 11:25, Nageswara Sastry wrote: > > > On 17/02/22 10:03 pm, Kajol Jain wrote: >> Patchset adds performance stats reporting support for nvdimm. >> Added interface includes support for pmu register/unregister >> functions. A structure is added called nvdimm_pmu to be used for >> adding arch/platform specific data such as cpumask, nvdimm device >> pointer and pmu event functions like event_init/add/read/del. >> User could use the standard perf tool to access perf events >> exposed via pmu. >> >> Interface also defines supported event list, config fields for the >> event attributes and their corresponding bit values which are exported >> via sysfs. Patch 3 exposes IBM pseries platform nmem* device >> performance stats using this interface. >> >> Result from power9 pseries lpar with 2 nvdimm device: >> >> Ex: List all event by perf list >> >> command:# perf list nmem >> >> nmem0/cache_rh_cnt/ [Kernel PMU event] >> nmem0/cache_wh_cnt/ [Kernel PMU event] >> nmem0/cri_res_util/ [Kernel PMU event] >> nmem0/ctl_res_cnt/ [Kernel PMU event] >> nmem0/ctl_res_tm/ [Kernel PMU event] >> nmem0/fast_w_cnt/ [Kernel PMU event] >> nmem0/host_l_cnt/ [Kernel PMU event] >> nmem0/host_l_dur/ [Kernel PMU event] >> nmem0/host_s_cnt/ [Kernel PMU event] >> nmem0/host_s_dur/ [Kernel PMU event] >> nmem0/med_r_cnt/ [Kernel PMU event] >> nmem0/med_r_dur/ [Kernel PMU event] >> nmem0/med_w_cnt/ [Kernel PMU event] >> nmem0/med_w_dur/ [Kernel PMU event] >> nmem0/mem_life/ [Kernel PMU event] >> nmem0/poweron_secs/ [Kernel PMU event] >> ... >> nmem1/mem_life/ [Kernel PMU event] >> nmem1/poweron_secs/ [Kernel PMU event] >> >> Patch1: >> Introduces the nvdimm_pmu structure >> Patch2: >> Adds common interface to add arch/platform specific data >> includes nvdimm device pointer, pmu data along with >> pmu event functions. It also defines supported event list >> and adds attribute groups for format, events and cpumask. >> It also adds code for cpu hotplug support. >> Patch3: >> Add code in arch/powerpc/platform/pseries/papr_scm.c to expose >> nmem* pmu. It fills in the nvdimm_pmu structure with pmu name, >> capabilities, cpumask and event functions and then registers >> the pmu by adding callbacks to register_nvdimm_pmu. >> Patch4: >> Sysfs documentation patch >> >> Changelog > > Tested these patches with the automated tests at > avocado-misc-tests/perf/perf_nmem.py > URL: > https://github.com/avocado-framework-tests/avocado-misc-tests/blob/master/perf/perf_nmem.py > > > 1. On the system where target id and online id were different then not > seeing value in 'cpumask' and those tests failed. > > Example: > Log from dmesg > ... > papr_scm ibm,persistent-memory:ibm,pmemory@4413: Region registered > with target node 1 and online node 0 > ... Hi Nageswara Sastry, Thanks for testing the patch set. Yes you right, incase target node id and online node id is different, it can happen when target node is not online and hence can cause this issue, thanks for pointing it. Function dev_to_node will return node id for a given nvdimm device which can be offline in some scenarios. We should use numa node id return by numa_map_to_online_node function in that scenario. This function incase given node is offline, it will lookup for next closest online node and return that nodeid. Can you try with below change and see, if you are still getting this issue. Please let me know. diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c index bdf2620db461..4dd513d7c029 100644 --- a/arch/powerpc/platforms/pseries/papr_scm.c +++ b/arch/powerpc/platforms/pseries/papr_scm.c @@ -536,7 +536,7 @@ static void papr_scm_pmu_register(struct papr_scm_priv *p) PERF_PMU_CAP_NO_EXCLUDE; /*updating the cpumask variable */ - nodeid = dev_to_node(>pdev->dev); + nodeid = numa_map_to_online_node(dev_to_node(>pdev->dev)); nd_pmu->arch_cpumask = *cpumask_of_node(nodeid); Thanks, Kajol Jain > > tests log: > (1/9) perf_nmem.py:perfNMEM.test_pmu_register_dmesg: PASS (1.13 s) > (2/9) perf_nmem.py:perfNMEM.test_sysfs: PASS (1.10 s) > (3/9) perf_nmem.py:perfNMEM.test_pmu_count: PASS (1.07 s) > (4/9)
Re: [PATCH v6 0/4] Add perf interface to expose nvdimm
On 2/24/22 02:47, Dan Williams wrote: > On Wed, Feb 23, 2022 at 11:07 AM Dan Williams > wrote: >> >> On Fri, Feb 18, 2022 at 10:06 AM Dan Williams >> wrote: >>> >>> On Thu, Feb 17, 2022 at 8:34 AM Kajol Jain wrote: Patchset adds performance stats reporting support for nvdimm. Added interface includes support for pmu register/unregister functions. A structure is added called nvdimm_pmu to be used for adding arch/platform specific data such as cpumask, nvdimm device pointer and pmu event functions like event_init/add/read/del. User could use the standard perf tool to access perf events exposed via pmu. Interface also defines supported event list, config fields for the event attributes and their corresponding bit values which are exported via sysfs. Patch 3 exposes IBM pseries platform nmem* device performance stats using this interface. Result from power9 pseries lpar with 2 nvdimm device: Ex: List all event by perf list command:# perf list nmem nmem0/cache_rh_cnt/[Kernel PMU event] nmem0/cache_wh_cnt/[Kernel PMU event] nmem0/cri_res_util/[Kernel PMU event] nmem0/ctl_res_cnt/ [Kernel PMU event] nmem0/ctl_res_tm/ [Kernel PMU event] nmem0/fast_w_cnt/ [Kernel PMU event] nmem0/host_l_cnt/ [Kernel PMU event] nmem0/host_l_dur/ [Kernel PMU event] nmem0/host_s_cnt/ [Kernel PMU event] nmem0/host_s_dur/ [Kernel PMU event] nmem0/med_r_cnt/ [Kernel PMU event] nmem0/med_r_dur/ [Kernel PMU event] nmem0/med_w_cnt/ [Kernel PMU event] nmem0/med_w_dur/ [Kernel PMU event] nmem0/mem_life/[Kernel PMU event] nmem0/poweron_secs/[Kernel PMU event] ... nmem1/mem_life/[Kernel PMU event] nmem1/poweron_secs/[Kernel PMU event] Patch1: Introduces the nvdimm_pmu structure Patch2: Adds common interface to add arch/platform specific data includes nvdimm device pointer, pmu data along with pmu event functions. It also defines supported event list and adds attribute groups for format, events and cpumask. It also adds code for cpu hotplug support. Patch3: Add code in arch/powerpc/platform/pseries/papr_scm.c to expose nmem* pmu. It fills in the nvdimm_pmu structure with pmu name, capabilities, cpumask and event functions and then registers the pmu by adding callbacks to register_nvdimm_pmu. Patch4: Sysfs documentation patch Changelog --- Resend v5 -> v6 - No logic change, just a rebase to latest upstream and tested the patchset. - Link to the patchset Resend v5: https://lkml.org/lkml/2021/11/15/3979 v5 -> Resend v5 - Resend the patchset - Link to the patchset v5: https://lkml.org/lkml/2021/9/28/643 v4 -> v5: - Remove multiple variables defined in nvdimm_pmu structure include name and pmu functions(event_int/add/del/read) as they are just used to copy them again in pmu variable. Now we are directly doing this step in arch specific code as suggested by Dan Williams. - Remove attribute group field from nvdimm pmu structure and defined these attribute groups in common interface which includes format, event list along with cpumask as suggested by Dan Williams. Since we added static defination for attrbute groups needed in common interface, removes corresponding code from papr. - Add nvdimm pmu event list with event codes in the common interface. - Remove Acked-by/Reviewed-by/Tested-by tags as code is refactored to handle review comments from Dan. >>> >>> I don't think review comments should invalidate the Acked-by tags in >>> this case. Nothing fundamentally changed in the approach, and I would >>> like to have the perf ack before taking this through the nvdimm tree. >>> >>> Otherwise this looks good to me. >>> >>> Peter, might you have a chance to re-Ack this series, or any concerns >>> about me retrieving those Acks from the previous postings? >> >> Reached Peter offline and he refreshed his Acked-by. > > There's still time for the tags from: > > "Madhavan Srinivasan" > "Nageswara R
Re: [RESEND PATCH v5 0/4] Add perf interface to expose nvdimm
On 11/16/21 8:29 PM, LEROY Christophe wrote: > Hi > > Le 16/11/2021 à 05:49, Kajol Jain a écrit : >> Patchset adds performance stats reporting support for nvdimm. >> Added interface includes support for pmu register/unregister >> functions. A structure is added called nvdimm_pmu to be used for >> adding arch/platform specific data such as cpumask, nvdimm device >> pointer and pmu event functions like event_init/add/read/del. >> User could use the standard perf tool to access perf events >> exposed via pmu. >> >> Interface also defines supported event list, config fields for the >> event attributes and their corresponding bit values which are exported >> via sysfs. Patch 3 exposes IBM pseries platform nmem* device >> performance stats using this interface. > > You resending your v5 series ? Is there any news since your submittion > last month that's awaiting in patchwork here at > https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=264422 ? Hi Christophe, There is no code side changes from the last v5 version. Since, I am looking for reviews, again posted this patchset with RESEND tag. Thanks, Kajol Jain > > Christophe > > >> >> Result from power9 pseries lpar with 2 nvdimm device: >> >> Ex: List all event by perf list >> >> command:# perf list nmem >> >>nmem0/cache_rh_cnt/[Kernel PMU event] >>nmem0/cache_wh_cnt/[Kernel PMU event] >>nmem0/cri_res_util/[Kernel PMU event] >>nmem0/ctl_res_cnt/ [Kernel PMU event] >>nmem0/ctl_res_tm/ [Kernel PMU event] >>nmem0/fast_w_cnt/ [Kernel PMU event] >>nmem0/host_l_cnt/ [Kernel PMU event] >>nmem0/host_l_dur/ [Kernel PMU event] >>nmem0/host_s_cnt/ [Kernel PMU event] >>nmem0/host_s_dur/ [Kernel PMU event] >>nmem0/med_r_cnt/ [Kernel PMU event] >>nmem0/med_r_dur/ [Kernel PMU event] >>nmem0/med_w_cnt/ [Kernel PMU event] >>nmem0/med_w_dur/ [Kernel PMU event] >>nmem0/mem_life/[Kernel PMU event] >>nmem0/poweron_secs/[Kernel PMU event] >>... >>nmem1/mem_life/[Kernel PMU event] >>nmem1/poweron_secs/[Kernel PMU event] >> >> Patch1: >> Introduces the nvdimm_pmu structure >> Patch2: >> Adds common interface to add arch/platform specific data >> includes nvdimm device pointer, pmu data along with >> pmu event functions. It also defines supported event list >> and adds attribute groups for format, events and cpumask. >> It also adds code for cpu hotplug support. >> Patch3: >> Add code in arch/powerpc/platform/pseries/papr_scm.c to expose >> nmem* pmu. It fills in the nvdimm_pmu structure with pmu name, >> capabilities, cpumask and event functions and then registers >> the pmu by adding callbacks to register_nvdimm_pmu. >> Patch4: >> Sysfs documentation patch >> >> Changelog >> --- >> v4 -> v5: >> - Remove multiple variables defined in nvdimm_pmu structure include >>name and pmu functions(event_int/add/del/read) as they are just >>used to copy them again in pmu variable. Now we are directly doing >>this step in arch specific code as suggested by Dan Williams. >> >> - Remove attribute group field from nvdimm pmu structure and >>defined these attribute groups in common interface which >>includes format, event list along with cpumask as suggested by >>Dan Williams. >>Since we added static defination for attrbute groups needed in >>common interface, removes corresponding code from papr. >> >> - Add nvdimm pmu event list with event codes in the common interface. >> >> - Remove Acked-by/Reviewed-by/Tested-by tags as code is refactored >>to handle review comments from Dan. >> >> - Make nvdimm_pmu_free_hotplug_memory function static as reported >>by kernel test robot, also add corresponding Reported-by tag. >> >> - Link to the patchset v4: https://lkml.org/lkml/2021/9/3/45 >> >> v3 -> v4 >> - Rebase code on top of current papr_scm code without any logical >>changes. >> >> - Added Acked-by tag from Peter Zijlstra and Reviewed by tag >>from Madhavan Srinivasan. >> >> - Link to the patchset v3: https://lkml.org/lkml/2021/6/17/605 >> >> v2 -> v3 >> - Added Tested-by tag. >> >> - Fix nvdimm mailing list in the ABI Documentation. >> >> - Link to the patchset v2: https://lkml.org/lkml/2021/6/14/25 >> >> v1 -> v2 >> - Fix hotplug code by adding pmu migration call >>
Re: [PATCH v2] perf vendor events power10: Add metric events json file for power10 platform
On 10/26/21 3:28 PM, kajoljain wrote:
>
>
> On 10/22/21 8:19 PM, Paul A. Clarke wrote:
>> Thanks for the changes!
>> More nits below (many left over from prior review)...
>>
>> On Fri, Oct 22, 2021 at 11:55:05AM +0530, Kajol Jain wrote:
>>> Add pmu metric json file for power10 platform.
>>>
>>> Signed-off-by: Kajol Jain
>>> ---
>>> Changelog v1 -> v2:
>>> - Did some nit changes in BriefDescription field
>>> as suggested by Paul A. Clarke
>>>
>>> - Link to the v1 patch: https://lkml.org/lkml/2021/10/6/131
>>>
>>> .../arch/powerpc/power10/metrics.json | 676 ++
>>> 1 file changed, 676 insertions(+)
>>> create mode 100644 tools/perf/pmu-events/arch/powerpc/power10/metrics.json
>>>
>>> diff --git a/tools/perf/pmu-events/arch/powerpc/power10/metrics.json
>>> b/tools/perf/pmu-events/arch/powerpc/power10/metrics.json
>>> new file mode 100644
>>> index ..8adab5cd9934
>>> --- /dev/null
>>> +++ b/tools/perf/pmu-events/arch/powerpc/power10/metrics.json
>>> @@ -0,0 +1,676 @@
>>> +[
>>> +{
>>> +"BriefDescription": "Percentage of cycles that are run cycles",
>>> +"MetricExpr": "PM_RUN_CYC / PM_CYC * 100",
>>> +"MetricGroup": "General",
>>> +"MetricName": "RUN_CYCLES_RATE",
>>> +"ScaleUnit": "1%"
>>> +},
>>> +{
>>> +"BriefDescription": "Average cycles per completed instruction",
>>> +"MetricExpr": "PM_CYC / PM_INST_CMPL",
>>> +"MetricGroup": "CPI",
>>> +"MetricName": "CYCLES_PER_INSTRUCTION"
>>> +},
>>> +{
>>> +"BriefDescription": "Average cycles per instruction when dispatch
>>> was stalled for any reason",
>>> +"MetricExpr": "PM_DISP_STALL_CYC / PM_RUN_INST_CMPL",
>>> +"MetricGroup": "CPI",
>>> +"MetricName": "DISPATCHED_CPI"
>>> +},
>>> +{
>>> +"BriefDescription": "Average cycles per instruction when dispatch
>>> was stalled because there was a flush",
>>> +"MetricExpr": "PM_DISP_STALL_FLUSH / PM_RUN_INST_CMPL",
>>> +"MetricGroup": "CPI",
>>> +"MetricName": "DISPATCHED_FLUSH_CPI"
>>> +},
>>> +{
>>> +"BriefDescription": "Average cycles per instruction when dispatch
>>> was stalled because the MMU was handling a translation miss",
>>> +"MetricExpr": "PM_DISP_STALL_TRANSLATION / PM_RUN_INST_CMPL",
>>> +"MetricGroup": "CPI",
>>> +"MetricName": "DISPATCHED_TRANSLATION_CPI"
>>> +},
>>> +{
>>> +"BriefDescription": "Average cycles per instruction when dispatch
>>> was stalled waiting to resolve an instruction ERAT miss",
>>> +"MetricExpr": "PM_DISP_STALL_IERAT_ONLY_MISS / PM_RUN_INST_CMPL",
>>> +"MetricGroup": "CPI",
>>> +"MetricName": "DISPATCHED_IERAT_ONLY_MISS_CPI"
>>> +},
>>> +{
>>> +"BriefDescription": "Average cycles per instruction when dispatch
>>> was stalled waiting to resolve an instruction TLB miss",
>>> +"MetricExpr": "PM_DISP_STALL_ITLB_MISS / PM_RUN_INST_CMPL",
>>> +"MetricGroup": "CPI",
>>> +"MetricName": "DISPATCHED_ITLB_MISS_CPI"
>>> +},
>>> +{
>>> +"BriefDescription": "Average cycles per instruction when dispatch
>>> was stalled due to an icache miss",
>>> +"MetricExpr": "PM_DISP_STALL_IC_MISS / PM_RUN_INST_CMPL",
>>> +"MetricGroup": "CPI",
>>> +"MetricName": "DISPATCHED_IC_MISS_CPI"
>>> +},
>>> +{
>>> +"BriefDescription": "Average cycles per instruction when dispatch
>>> was stalled while the in
Re: [PATCH v2] perf vendor events power10: Add metric events json file for power10 platform
On 10/25/21 5:36 PM, Paul A. Clarke wrote:
> On Mon, Oct 25, 2021 at 02:23:15PM +1100, Michael Ellerman wrote:
>> "Paul A. Clarke" writes:
>>> Thanks for the changes!
>>> More nits below (many left over from prior review)...
>>>
>>> On Fri, Oct 22, 2021 at 11:55:05AM +0530, Kajol Jain wrote:
Add pmu metric json file for power10 platform.
Signed-off-by: Kajol Jain
---
Changelog v1 -> v2:
- Did some nit changes in BriefDescription field
as suggested by Paul A. Clarke
- Link to the v1 patch: https://lkml.org/lkml/2021/10/6/131
.../arch/powerpc/power10/metrics.json | 676 ++
1 file changed, 676 insertions(+)
create mode 100644 tools/perf/pmu-events/arch/powerpc/power10/metrics.json
diff --git a/tools/perf/pmu-events/arch/powerpc/power10/metrics.json
b/tools/perf/pmu-events/arch/powerpc/power10/metrics.json
new file mode 100644
index ..8adab5cd9934
--- /dev/null
+++ b/tools/perf/pmu-events/arch/powerpc/power10/metrics.json
@@ -0,0 +1,676 @@
+[
+{
+"BriefDescription": "Percentage of cycles that are run cycles",
+"MetricExpr": "PM_RUN_CYC / PM_CYC * 100",
+"MetricGroup": "General",
+"MetricName": "RUN_CYCLES_RATE",
+"ScaleUnit": "1%"
+},
+{
+"BriefDescription": "Average cycles per completed instruction",
+"MetricExpr": "PM_CYC / PM_INST_CMPL",
+"MetricGroup": "CPI",
+"MetricName": "CYCLES_PER_INSTRUCTION"
+},
+{
+"BriefDescription": "Average cycles per instruction when dispatch
was stalled for any reason",
+"MetricExpr": "PM_DISP_STALL_CYC / PM_RUN_INST_CMPL",
+"MetricGroup": "CPI",
+"MetricName": "DISPATCHED_CPI"
+},
+{
+"BriefDescription": "Average cycles per instruction when dispatch
was stalled because there was a flush",
+"MetricExpr": "PM_DISP_STALL_FLUSH / PM_RUN_INST_CMPL",
+"MetricGroup": "CPI",
+"MetricName": "DISPATCHED_FLUSH_CPI"
+},
+{
+"BriefDescription": "Average cycles per instruction when dispatch
was stalled because the MMU was handling a translation miss",
+"MetricExpr": "PM_DISP_STALL_TRANSLATION / PM_RUN_INST_CMPL",
+"MetricGroup": "CPI",
+"MetricName": "DISPATCHED_TRANSLATION_CPI"
+},
+{
+"BriefDescription": "Average cycles per instruction when dispatch
was stalled waiting to resolve an instruction ERAT miss",
+"MetricExpr": "PM_DISP_STALL_IERAT_ONLY_MISS / PM_RUN_INST_CMPL",
+"MetricGroup": "CPI",
+"MetricName": "DISPATCHED_IERAT_ONLY_MISS_CPI"
+},
+{
+"BriefDescription": "Average cycles per instruction when dispatch
was stalled waiting to resolve an instruction TLB miss",
+"MetricExpr": "PM_DISP_STALL_ITLB_MISS / PM_RUN_INST_CMPL",
+"MetricGroup": "CPI",
+"MetricName": "DISPATCHED_ITLB_MISS_CPI"
+},
+{
+"BriefDescription": "Average cycles per instruction when dispatch
was stalled due to an icache miss",
+"MetricExpr": "PM_DISP_STALL_IC_MISS / PM_RUN_INST_CMPL",
+"MetricGroup": "CPI",
+"MetricName": "DISPATCHED_IC_MISS_CPI"
+},
+{
+"BriefDescription": "Average cycles per instruction when dispatch
was stalled while the instruction was fetched from the local L2",
+"MetricExpr": "PM_DISP_STALL_IC_L2 / PM_RUN_INST_CMPL",
+"MetricGroup": "CPI",
+"MetricName": "DISPATCHED_IC_L2_CPI"
+},
+{
+"BriefDescription": "Average cycles per instruction when dispatch
was stalled while the instruction was fetched from the local L3",
+"MetricExpr": "PM_DISP_STALL_IC_L3 / PM_RUN_INST_CMPL",
+"MetricGroup": "CPI",
+"MetricName": "DISPATCHED_IC_L3_CPI"
+},
+{
+"BriefDescription": "Average cycles per instruction when dispatch
was stalled while the instruction was fetched from any source beyond the
local L3",
+"MetricExpr": "PM_DISP_STALL_IC_L3MISS / PM_RUN_INST_CMPL",
+"MetricGroup": "CPI",
+"MetricName": "DISPATCHED_IC_L3MISS_CPI"
+},
+{
+"BriefDescription": "Average cycles per instruction when dispatch
was stalled due to an icache miss after a branch mispredict",
+"MetricExpr": "PM_DISP_STALL_BR_MPRED_ICMISS / PM_RUN_INST_CMPL",
+"MetricGroup": "CPI",
+"MetricName": "DISPATCHED_BR_MPRED_ICMISS_CPI"
+},
+{
+"BriefDescription": "Average
Re: [PATCH v2] perf vendor events power10: Add metric events json file for power10 platform
On 10/22/21 8:19 PM, Paul A. Clarke wrote:
> Thanks for the changes!
> More nits below (many left over from prior review)...
>
> On Fri, Oct 22, 2021 at 11:55:05AM +0530, Kajol Jain wrote:
>> Add pmu metric json file for power10 platform.
>>
>> Signed-off-by: Kajol Jain
>> ---
>> Changelog v1 -> v2:
>> - Did some nit changes in BriefDescription field
>> as suggested by Paul A. Clarke
>>
>> - Link to the v1 patch: https://lkml.org/lkml/2021/10/6/131
>>
>> .../arch/powerpc/power10/metrics.json | 676 ++
>> 1 file changed, 676 insertions(+)
>> create mode 100644 tools/perf/pmu-events/arch/powerpc/power10/metrics.json
>>
>> diff --git a/tools/perf/pmu-events/arch/powerpc/power10/metrics.json
>> b/tools/perf/pmu-events/arch/powerpc/power10/metrics.json
>> new file mode 100644
>> index ..8adab5cd9934
>> --- /dev/null
>> +++ b/tools/perf/pmu-events/arch/powerpc/power10/metrics.json
>> @@ -0,0 +1,676 @@
>> +[
>> +{
>> +"BriefDescription": "Percentage of cycles that are run cycles",
>> +"MetricExpr": "PM_RUN_CYC / PM_CYC * 100",
>> +"MetricGroup": "General",
>> +"MetricName": "RUN_CYCLES_RATE",
>> +"ScaleUnit": "1%"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per completed instruction",
>> +"MetricExpr": "PM_CYC / PM_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "CYCLES_PER_INSTRUCTION"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled for any reason",
>> +"MetricExpr": "PM_DISP_STALL_CYC / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_CPI"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled because there was a flush",
>> +"MetricExpr": "PM_DISP_STALL_FLUSH / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_FLUSH_CPI"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled because the MMU was handling a translation miss",
>> +"MetricExpr": "PM_DISP_STALL_TRANSLATION / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_TRANSLATION_CPI"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled waiting to resolve an instruction ERAT miss",
>> +"MetricExpr": "PM_DISP_STALL_IERAT_ONLY_MISS / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_IERAT_ONLY_MISS_CPI"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled waiting to resolve an instruction TLB miss",
>> +"MetricExpr": "PM_DISP_STALL_ITLB_MISS / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_ITLB_MISS_CPI"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled due to an icache miss",
>> +"MetricExpr": "PM_DISP_STALL_IC_MISS / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_IC_MISS_CPI"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled while the instruction was fetched from the local L2",
>> +"MetricExpr": "PM_DISP_STALL_IC_L2 / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_IC_L2_CPI"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled while the instruction was fetched from the local L3",
>> +"MetricExpr": "PM_DISP_STALL_IC_L3 / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_IC_L3_CPI"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled while the instruction was fetched from any source beyond the
>> local L3",
>> +"MetricExpr": "PM_DISP_STALL_IC_L3MISS / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_IC_L3MISS_CPI"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled due to an icache miss after a branch mispredict",
>> +"MetricExpr": "PM_DISP_STALL_BR_MPRED_ICMISS / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_BR_MPRED_ICMISS_CPI"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled while instruction was fetched from the local L2 after suffering
>> a branch mispredict",
>> +"MetricExpr": "PM_DISP_STALL_BR_MPRED_IC_L2 / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_BR_MPRED_IC_L2_CPI"
>> +
Re: [PATCH v5 0/4] Add perf interface to expose nvdimm
Hi Dan, Any comments on this patch-set? Thanks, Kajol Jain On 9/28/21 6:11 PM, Kajol Jain wrote: > Patchset adds performance stats reporting support for nvdimm. > Added interface includes support for pmu register/unregister > functions. A structure is added called nvdimm_pmu to be used for > adding arch/platform specific data such as cpumask, nvdimm device > pointer and pmu event functions like event_init/add/read/del. > User could use the standard perf tool to access perf events > exposed via pmu. > > Interface also defines supported event list, config fields for the > event attributes and their corresponding bit values which are exported > via sysfs. Patch 3 exposes IBM pseries platform nmem* device > performance stats using this interface. > > Result from power9 pseries lpar with 2 nvdimm device: > > Ex: List all event by perf list > > command:# perf list nmem > > nmem0/cache_rh_cnt/[Kernel PMU event] > nmem0/cache_wh_cnt/[Kernel PMU event] > nmem0/cri_res_util/[Kernel PMU event] > nmem0/ctl_res_cnt/ [Kernel PMU event] > nmem0/ctl_res_tm/ [Kernel PMU event] > nmem0/fast_w_cnt/ [Kernel PMU event] > nmem0/host_l_cnt/ [Kernel PMU event] > nmem0/host_l_dur/ [Kernel PMU event] > nmem0/host_s_cnt/ [Kernel PMU event] > nmem0/host_s_dur/ [Kernel PMU event] > nmem0/med_r_cnt/ [Kernel PMU event] > nmem0/med_r_dur/ [Kernel PMU event] > nmem0/med_w_cnt/ [Kernel PMU event] > nmem0/med_w_dur/ [Kernel PMU event] > nmem0/mem_life/[Kernel PMU event] > nmem0/poweron_secs/[Kernel PMU event] > ... > nmem1/mem_life/[Kernel PMU event] > nmem1/poweron_secs/[Kernel PMU event] > > Patch1: > Introduces the nvdimm_pmu structure > Patch2: > Adds common interface to add arch/platform specific data > includes nvdimm device pointer, pmu data along with > pmu event functions. It also defines supported event list > and adds attribute groups for format, events and cpumask. > It also adds code for cpu hotplug support. > Patch3: > Add code in arch/powerpc/platform/pseries/papr_scm.c to expose > nmem* pmu. It fills in the nvdimm_pmu structure with pmu name, > capabilities, cpumask and event functions and then registers > the pmu by adding callbacks to register_nvdimm_pmu. > Patch4: > Sysfs documentation patch > > Changelog > --- > v4 -> v5: > - Remove multiple variables defined in nvdimm_pmu structure include > name and pmu functions(event_int/add/del/read) as they are just > used to copy them again in pmu variable. Now we are directly doing > this step in arch specific code as suggested by Dan Williams. > > - Remove attribute group field from nvdimm pmu structure and > defined these attribute groups in common interface which > includes format, event list along with cpumask as suggested by > Dan Williams. > Since we added static defination for attrbute groups needed in > common interface, removes corresponding code from papr. > > - Add nvdimm pmu event list with event codes in the common interface. > > - Remove Acked-by/Reviewed-by/Tested-by tags as code is refactored > to handle review comments from Dan. > > - Make nvdimm_pmu_free_hotplug_memory function static as reported > by kernel test robot, also add corresponding Reported-by tag. > > - Link to the patchset v4: https://lkml.org/lkml/2021/9/3/45 > > v3 -> v4 > - Rebase code on top of current papr_scm code without any logical > changes. > > - Added Acked-by tag from Peter Zijlstra and Reviewed by tag > from Madhavan Srinivasan. > > - Link to the patchset v3: https://lkml.org/lkml/2021/6/17/605 > > v2 -> v3 > - Added Tested-by tag. > > - Fix nvdimm mailing list in the ABI Documentation. > > - Link to the patchset v2: https://lkml.org/lkml/2021/6/14/25 > > v1 -> v2 > - Fix hotplug code by adding pmu migration call > incase current designated cpu got offline. As > pointed by Peter Zijlstra. > > - Removed the retun -1 part from cpu hotplug offline > function. > > - Link to the patchset v1: https://lkml.org/lkml/2021/6/8/500 > > Kajol Jain (4): > drivers/nvdimm: Add nvdimm pmu structure > drivers/nvdimm: Add perf interface to expose nvdimm performance stats > powerpc/papr_scm: Add perf interface support > docs: ABI: sysfs-bus-nvdimm: Document sysfs event format entries for > nvdimm pmu > >
Re: [V3 0/4] powerpc/perf: Add instruction and data address registers to extended regs
On 10/7/21 12:25 PM, Athira Rajeev wrote: > Patch set adds PMU registers namely Sampled Instruction Address Register > (SIAR) and Sampled Data Address Register (SDAR) as part of extended regs > in PowerPC. These registers provides the instruction/data address and > adding these to extended regs helps in debug purposes. > > Patch 1/4 and 2/4 refactors the existing macro definition of > PERF_REG_PMU_MASK_300 and PERF_REG_PMU_MASK_31 to make it more > readable. > Patch 3/4 adds SIAR and SDAR as part of the extended regs mask. > Patch 4/4 includes perf tools side changes to add the SPRs to > sample_reg_mask to use with -I? option. > > Changelog: > Change from v2 -> v3: > Addressed review comments from Michael Ellerman > - Fixed the macro definition to use "unsigned long long" > which otherwise will cause build error with perf on > 32-bit. > - Added Reviewed-by from Daniel Axtens for patch3. > > Change from v1 -> v2: > Addressed review comments from Michael Ellerman > - Refactored the perf reg extended mask value macros for > PERF_REG_PMU_MASK_300 and PERF_REG_PMU_MASK_31 to > make it more readable. Also moved PERF_REG_EXTENDED_MAX > along with enum definition similar to PERF_REG_POWERPC_MAX. > > Athira Rajeev (4): > powerpc/perf: Refactor the code definition of perf reg extended mask > tools/perf: Refactor the code definition of perf reg extended mask in > tools side header file > powerpc/perf: Expose instruction and data address registers as part of > extended regs > tools/perf: Add perf tools support to expose instruction and data > address registers as part of extended regs Patch-set looks good to me. Reviewed-by: Kajol Jain Thanks, Kajol Jain > > arch/powerpc/include/uapi/asm/perf_regs.h | 28 --- > arch/powerpc/perf/perf_regs.c | 4 +++ > .../arch/powerpc/include/uapi/asm/perf_regs.h | 28 --- > tools/perf/arch/powerpc/include/perf_regs.h | 2 ++ > tools/perf/arch/powerpc/util/perf_regs.c | 2 ++ > 5 files changed, 44 insertions(+), 20 deletions(-) >
Re: [PATCH] perf vendor events power10: Add metric events json file for power10 platform
On 10/6/21 11:02 PM, Paul A. Clarke wrote:
> Kajol,
>
> On Wed, Oct 06, 2021 at 01:01:19PM +0530, Kajol Jain wrote:
>> Add pmu metric json file for power10 platform.
>
> Thanks for producing this! A few minor corrections, plus a number of
> stylistic comments below...
Hi Paul,
I will make mentioned nit changes and send a v2.
Thanks,
Kajol Jain
>
>> Signed-off-by: Kajol Jain
>> ---
>> .../arch/powerpc/power10/metrics.json | 772 ++
>> 1 file changed, 772 insertions(+)
>> create mode 100644 tools/perf/pmu-events/arch/powerpc/power10/metrics.json
>>
>> diff --git a/tools/perf/pmu-events/arch/powerpc/power10/metrics.json
>> b/tools/perf/pmu-events/arch/powerpc/power10/metrics.json
>> new file mode 100644
>> index ..028c9777a516
>> --- /dev/null
>> +++ b/tools/perf/pmu-events/arch/powerpc/power10/metrics.json
>> @@ -0,0 +1,772 @@
>> +[
>> +{
>> +"BriefDescription": "Percentage of cycles that are run cycles",
>> +"MetricExpr": "PM_RUN_CYC / PM_CYC * 100",
>> +"MetricGroup": "General",
>> +"MetricName": "RUN_CYCLES_RATE",
>> +"ScaleUnit": "1%"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per completed instruction",
>> +"MetricExpr": "PM_CYC / PM_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "CYCLES_PER_INSTRUCTION"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled for any reason",
>> +"MetricExpr": "PM_DISP_STALL_CYC / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_CPI"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled because there was a flush",
>> +"MetricExpr": "PM_DISP_STALL_FLUSH / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_FLUSH_CPI"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled because the MMU was handling a translation miss",
>> +"MetricExpr": "PM_DISP_STALL_TRANSLATION / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_TRANSLATION_CPI"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled waiting to resolve an instruction ERAT miss",
>> +"MetricExpr": "PM_DISP_STALL_IERAT_ONLY_MISS / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_IERAT_ONLY_MISS_CPI"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled waiting to resolve an instruction TLB miss",
>> +"MetricExpr": "PM_DISP_STALL_ITLB_MISS / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_ITLB_MISS_CPI"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled due to an icache miss",
>> +"MetricExpr": "PM_DISP_STALL_IC_MISS / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_IC_MISS_CPI"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled while the instruction was fetched form the local L2",
>
> s/form/from/
>
>> +"MetricExpr": "PM_DISP_STALL_IC_L2 / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_IC_L2_CPI"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled while the instruction was fetched form the local L3",
>
> s/form/from/
>
>> +"MetricExpr": "PM_DISP_STALL_IC_L3 / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_IC_L3_CPI"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled while the instruction was fetched from any source beyond the
>> local L3",
>> +"MetricExpr": "PM_DISP_STALL_IC_L3MISS / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_IC_L3MISS_CPI"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled due to an icache miss after a branch mispredict",
>> +"MetricExpr": "PM_DISP_STALL_BR_MPRED_ICMISS / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_BR_MPRED_ICMISS_CPI"
>> +},
>> +{
>> +"BriefDescription": "Average cycles per instruction when dispatch
>> was stalled while instruction was fetched from the local L2 after suffering
>> a branch mispredict",
>> +"MetricExpr": "PM_DISP_STALL_BR_MPRED_IC_L2 / PM_RUN_INST_CMPL",
>> +"MetricGroup": "CPI",
>> +"MetricName": "DISPATCHED_BR_MPRED_IC_L2_CPI"
>> +},
>> +{
>> +
Re: [PATCH 2/4] perf: Add mem_hops field in perf_mem_data_src structure
On 10/6/21 1:50 AM, Peter Zijlstra wrote:
> On Tue, Oct 05, 2021 at 02:48:35PM +0530, Kajol Jain wrote:
>> Going forward, future generation systems can have more hierarchy
>> within the chip/package level but currently we don't have any data source
>> encoding field in perf, which can be used to represent this level of data.
>>
>> Add a new field called 'mem_hops' in the perf_mem_data_src structure
>> which can be used to represent intra-chip/package or inter-chip/off-package
>> details. This field is of size 3 bits where PERF_MEM_HOPS_{NA, 0..6} value
>> can be used to present different hop levels data.
>>
>> Also add corresponding macros to define mem_hop field values
>> and shift value.
>>
>> Currently we define macro for HOPS_0 which corresponds
>> to data coming from another core but same chip.
>>
>> For ex: Encodings for mem_hops fields with L2 cache:
>>
>> L2 - local L2
>> L2 | REMOTE | HOPS_0 - remote core, same chip L2
>
> Can we do s/chip/node/ ? Hops are something NUMA related, while chips
> come in a bag or something :-)
Hi Peter,
Sure, I will make this change in next version of this patch-set.
Thanks,
Kajol Jain
>
>> +/* hop level */
>> +#define PERF_MEM_HOPS_0 0x01 /* remote core, same chip */
>> +/* 2-7 available */
>> +#define PERF_MEM_HOPS_SHIFT 43
Re: [PATCH 1/4] perf: Add comment about current state of PERF_MEM_LVL_* namespace and remove an extra line
Hi,
Sorry I missed to update correct version details.
Link to the previous patch-set, where discussion related to addition of
new data source encoding field 'mem_hops' happened:
https://lkml.org/lkml/2021/9/4/37
Changelog:
- Rather then adding new macros for L2.1/L3.1 (same chip, different
core) entries as part of field lvlnum, we are introducing new field
called 'mem_hops' which can be used to get hops
level data(intra-chip/package or inter-chip/off-package details).
As suggested by Peter Zijlstra.
- Using OnChip to denote data accesses from 'another core of same chip'
is not too clear. Update it to 'remote core, same chip' as pointed by
Michael Ellerman.
- Update the fix patch of correcting data source encodings to use new
added field 'mem_hops'.
Thanks,
Kajol Jain
On 10/5/21 2:48 PM, Kajol Jain wrote:
> Add a comment about PERF_MEM_LVL_* namespace being depricated
> to some extent in favour of added PERF_MEM_{LVLNUM_,REMOTE_,SNOOPX_}
> fields.
>
> Remove an extra line present in perf_mem__lvl_scnprintf function.
>
> Signed-off-by: Kajol Jain
> ---
> include/uapi/linux/perf_event.h | 8 +++-
> tools/include/uapi/linux/perf_event.h | 8 +++-
> tools/perf/util/mem-events.c | 1 -
> 3 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index f92880a15645..e1701e9c7858 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -1241,7 +1241,13 @@ union perf_mem_data_src {
> #define PERF_MEM_OP_EXEC 0x10 /* code (execution) */
> #define PERF_MEM_OP_SHIFT0
>
> -/* memory hierarchy (memory level, hit or miss) */
> +/*
> + * PERF_MEM_LVL_* namespace being depricated to some extent in the
> + * favour of newer composite PERF_MEM_{LVLNUM_,REMOTE_,SNOOPX_} fields.
> + * Supporting this namespace inorder to not break defined ABIs.
> + *
> + * memory hierarchy (memory level, hit or miss)
> + */
> #define PERF_MEM_LVL_NA 0x01 /* not available */
> #define PERF_MEM_LVL_HIT 0x02 /* hit level */
> #define PERF_MEM_LVL_MISS0x04 /* miss level */
> diff --git a/tools/include/uapi/linux/perf_event.h
> b/tools/include/uapi/linux/perf_event.h
> index f92880a15645..e1701e9c7858 100644
> --- a/tools/include/uapi/linux/perf_event.h
> +++ b/tools/include/uapi/linux/perf_event.h
> @@ -1241,7 +1241,13 @@ union perf_mem_data_src {
> #define PERF_MEM_OP_EXEC 0x10 /* code (execution) */
> #define PERF_MEM_OP_SHIFT0
>
> -/* memory hierarchy (memory level, hit or miss) */
> +/*
> + * PERF_MEM_LVL_* namespace being depricated to some extent in the
> + * favour of newer composite PERF_MEM_{LVLNUM_,REMOTE_,SNOOPX_} fields.
> + * Supporting this namespace inorder to not break defined ABIs.
> + *
> + * memory hierarchy (memory level, hit or miss)
> + */
> #define PERF_MEM_LVL_NA 0x01 /* not available */
> #define PERF_MEM_LVL_HIT 0x02 /* hit level */
> #define PERF_MEM_LVL_MISS0x04 /* miss level */
> diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
> index f0e75df72b80..ff7289e28192 100644
> --- a/tools/perf/util/mem-events.c
> +++ b/tools/perf/util/mem-events.c
> @@ -320,7 +320,6 @@ int perf_mem__lvl_scnprintf(char *out, size_t sz, struct
> mem_info *mem_info)
> /* already taken care of */
> m &= ~(PERF_MEM_LVL_HIT|PERF_MEM_LVL_MISS);
>
> -
> if (mem_info && mem_info->data_src.mem_remote) {
> strcat(out, "Remote ");
> l += 7;
>
Re: [RESEND PATCH v4 4/4] powerpc/papr_scm: Document papr_scm sysfs event format entries
On 9/8/21 6:33 AM, Dan Williams wrote: > On Thu, Sep 2, 2021 at 10:11 PM Kajol Jain wrote: >> >> Details is added for the event, cpumask and format attributes >> in the ABI documentation. >> >> Acked-by: Peter Zijlstra (Intel) >> Reviewed-by: Madhavan Srinivasan >> Tested-by: Nageswara R Sastry >> Signed-off-by: Kajol Jain >> --- >> Documentation/ABI/testing/sysfs-bus-papr-pmem | 31 +++ >> 1 file changed, 31 insertions(+) >> >> diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem >> b/Documentation/ABI/testing/sysfs-bus-papr-pmem >> index 95254cec92bf..4d86252448f8 100644 >> --- a/Documentation/ABI/testing/sysfs-bus-papr-pmem >> +++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem >> @@ -61,3 +61,34 @@ Description: >> * "CchRHCnt" : Cache Read Hit Count >> * "CchWHCnt" : Cache Write Hit Count >> * "FastWCnt" : Fast Write Count >> + >> +What: /sys/devices/nmemX/format >> +Date: June 2021 >> +Contact: linuxppc-dev , >> nvd...@lists.linux.dev, >> +Description: (RO) Attribute group to describe the magic bits >> +that go into perf_event_attr.config for a particular pmu. >> +(See ABI/testing/sysfs-bus-event_source-devices-format). >> + >> +Each attribute under this group defines a bit range of the >> +perf_event_attr.config. Supported attribute is listed >> +below:: >> + >> + event = "config:0-4" - event ID >> + >> + For example:: >> + noopstat = "event=0x1" >> + >> +What: /sys/devices/nmemX/events > > That's not a valid sysfs path. Did you mean /sys/bus/nd/devices/nmemX? Hi Dan, Thanks, I will correct it and update it to `/sys/bus/event_source/devices/` where perf creates sysfs files for given pmu. > >> +Date: June 2021 >> +Contact: linuxppc-dev , >> nvd...@lists.linux.dev, >> +Description:(RO) Attribute group to describe performance monitoring >> +events specific to papr-scm. Each attribute in this group >> describes >> +a single performance monitoring event supported by this >> nvdimm pmu. >> +The name of the file is the name of the event. >> +(See ABI/testing/sysfs-bus-event_source-devices-events). > > Given these events are in the generic namespace the ABI documentation > should be generic as well. So I think move these entries to > Documentation/ABI/testing/sysfs-bus-nvdimm directly. > > You can still mention papr-scm, but I would expect something like: > > What: /sys/bus/nd/devices/nmemX/events > Date: September 2021 > KernelVersion: 5.16 > Contact:Kajol Jain > Description: > (RO) Attribute group to describe performance monitoring events > for the nvdimm memory device. Each attribute in this group > describes a single performance monitoring event supported by > this nvdimm pmu. The name of the file is the name of the > event. > (See ABI/testing/sysfs-bus-event_source-devices-events). A > listing of the events supported by a given nvdimm provider > type > can be found in Documentation/driver-api/nvdimm/$provider, for > example: Documentation/driver-api/nvdimm/papr-scm. > > I will update it accordingly. > >> + >> +What: /sys/devices/nmemX/cpumask >> +Date: June 2021 >> +Contact: linuxppc-dev , >> nvd...@lists.linux.dev, >> +Description: (RO) This sysfs file exposes the cpumask which is designated >> to make >> +HCALLs to retrieve nvdimm pmu event counter data. > > Seems this one would be provider generic, so no need to refer to PPC > specific concepts like HCALLs. > Sure will update it. Thanks, Kajol Jain
Re: [RESEND PATCH v4 1/4] drivers/nvdimm: Add nvdimm pmu structure
On 9/8/21 3:29 AM, Dan Williams wrote:
> Hi Kajol,
>
> Apologies for the delay in responding to this series, some comments below:
Hi Dan,
No issues, thanks for reviewing the patches.
>
> On Thu, Sep 2, 2021 at 10:10 PM Kajol Jain wrote:
>>
>> A structure is added, called nvdimm_pmu, for performance
>> stats reporting support of nvdimm devices. It can be used to add
>> nvdimm pmu data such as supported events and pmu event functions
>> like event_init/add/read/del with cpu hotplug support.
>>
>> Acked-by: Peter Zijlstra (Intel)
>> Reviewed-by: Madhavan Srinivasan
>> Tested-by: Nageswara R Sastry
>> Signed-off-by: Kajol Jain
>> ---
>> include/linux/nd.h | 43 +++
>> 1 file changed, 43 insertions(+)
>>
>> diff --git a/include/linux/nd.h b/include/linux/nd.h
>> index ee9ad76afbba..712499cf7335 100644
>> --- a/include/linux/nd.h
>> +++ b/include/linux/nd.h
>> @@ -8,6 +8,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>>
>> enum nvdimm_event {
>> NVDIMM_REVALIDATE_POISON,
>> @@ -23,6 +25,47 @@ enum nvdimm_claim_class {
>> NVDIMM_CCLASS_UNKNOWN,
>> };
>>
>> +/* Event attribute array index */
>> +#define NVDIMM_PMU_FORMAT_ATTR 0
>> +#define NVDIMM_PMU_EVENT_ATTR 1
>> +#define NVDIMM_PMU_CPUMASK_ATTR2
>> +#define NVDIMM_PMU_NULL_ATTR 3
>> +
>> +/**
>> + * struct nvdimm_pmu - data structure for nvdimm perf driver
>> + *
>> + * @name: name of the nvdimm pmu device.
>> + * @pmu: pmu data structure for nvdimm performance stats.
>> + * @dev: nvdimm device pointer.
>> + * @functions(event_init/add/del/read): platform specific pmu functions.
>
> This is not valid kernel-doc:
>
> include/linux/nd.h:67: warning: Function parameter or member
> 'event_init' not described in 'nvdimm_pmu'
> include/linux/nd.h:67: warning: Function parameter or member 'add' not
> described in 'nvdimm_pmu'
> include/linux/nd.h:67: warning: Function parameter or member 'del' not
> described in 'nvdimm_pmu'
> include/linux/nd.h:67: warning: Function parameter or member 'read'
> not described in 'nvdimm_pmu'
>
> ...but I think rather than fixing those up 'struct nvdimm_pmu' should be
> pruned.
>
> It's not clear to me that it is worth the effort to describe these
> details to the nvdimm core which is just going to turn around and call
> the pmu core. I'd just as soon have the driver call the pmu core
> directly, optionally passing in attributes and callbacks that come
> from the nvdimm core and/or the nvdimm provider.
The intend for adding these callbacks(event_init/add/del/read) is to give
flexibility to the nvdimm core to add some common checks/routines if required
in the future. Those checks can be common for all architecture with still
having the
ability to call arch/platform specific driver code to use its own routines.
But as you said, currently we don't have any common checks and it directly
calling platform specific code, so we can get rid of it.
Should we remove this part for now?
>
> Otherwise it's also not clear which of these structure members are
> used at runtime vs purely used as temporary storage to pass parameters
> to the pmu core.
>
>> + * @attr_groups: data structure for events, formats and cpumask
>> + * @cpu: designated cpu for counter access.
>> + * @node: node for cpu hotplug notifier link.
>> + * @cpuhp_state: state for cpu hotplug notification.
>> + * @arch_cpumask: cpumask to get designated cpu for counter access.
>> + */
>> +struct nvdimm_pmu {
>> + const char *name;
>> + struct pmu pmu;
>> + struct device *dev;
>> + int (*event_init)(struct perf_event *event);
>> + int (*add)(struct perf_event *event, int flags);
>> + void (*del)(struct perf_event *event, int flags);
>> + void (*read)(struct perf_event *event);
>> + /*
>> +* Attribute groups for the nvdimm pmu. Index 0 used for
>> +* format attribute, index 1 used for event attribute,
>> +* index 2 used for cpusmask attribute and index 3 kept as NULL.
>> +*/
>> + const struct attribute_group *attr_groups[4];
>
> Following from above, I'd rather this was organized as static
> attributes with an is_visible() helper for the groups for any dynamic
> aspects. That mirrors the behavior of nvdimm_create() and allows for
> device drivers to compose the attribute groups from a core set and /
> or a provider specific set.
Since we don't have any common events right now, Can I use papr
attributes directly or should we create dummy events for common thing and
then merged it with papr event list.
Thanks,
Kajol Jain
>
>> + int cpu;
>> + struct hlist_node node;
>> + enum cpuhp_state cpuhp_state;
>> +
>> + /* cpumask provided by arch/platform specific code */
>> + struct cpumask arch_cpumask;
>> +};
>> +
>> struct nd_device_driver {
>> struct device_driver drv;
>> unsigned long type;
>> --
>>
Re: [PATCH 0/2] powerpc/perf: Add instruction and data address registers to extended regs
On 6/20/21 8:15 PM, Athira Rajeev wrote: > Patch set adds PMU registers namely Sampled Instruction Address Register > (SIAR) and Sampled Data Address Register (SDAR) as part of extended regs > in PowerPC. These registers provides the instruction/data address and > adding these to extended regs helps in debug purposes. > > Patch 1/2 adds SIAR and SDAR as part of the extended regs mask. > Patch 2/2 includes perf tools side changes to add the SPRs to > sample_reg_mask to use with -I? option. > > Athira Rajeev (2): > powerpc/perf: Expose instruction and data address registers as part of > extended regs > tools/perf: Add perf tools support to expose instruction and data > address registers as part of extended regs > Patchset looks good to me. Reviewed-By: kajol Jain Thanks, Kajol Jain > arch/powerpc/include/uapi/asm/perf_regs.h | 12 +++- > arch/powerpc/perf/perf_regs.c | 4 > tools/arch/powerpc/include/uapi/asm/perf_regs.h | 12 +++- > tools/perf/arch/powerpc/include/perf_regs.h | 2 ++ > tools/perf/arch/powerpc/util/perf_regs.c| 2 ++ > 5 files changed, 22 insertions(+), 10 deletions(-) >
Re: [PATCH v3 3/3] powerpc/perf: Fix the check for SIAR value
On 8/18/21 6:58 PM, Christophe Leroy wrote:
>
>
> Le 18/08/2021 à 15:19, Kajol Jain a écrit :
>> Incase of random sampling, there can be scenarios where
>> Sample Instruction Address Register(SIAR) may not latch
>> to the sampled instruction and could result in
>> the value of 0. In these scenarios it is preferred to
>> return regs->nip. These corner cases are seen in the
>> previous generation (p9) also.
>>
>> Patch adds the check for SIAR value along with use_siar and
>> siar_valid checks so that the function will return regs->nip
>> incase SIAR is zero.
>>
>> Patch drops the code under PPMU_P10_DD1 flag check
>> which handles SIAR 0 case only for Power10 DD1.
>>
>> Fixes: 2ca13a4cc56c9 ("powerpc/perf: Use regs->nip when SIAR is zero")
>> Signed-off-by: Kajol Jain
>> ---
>>
>> Changelog:
>> - Drop adding new ternary condition to check siar value.
>> - Remove siar check specific for PPMU_P10_DD1 and add
>> it along with common checks as suggested by Christophe Leroy
>> and Michael Ellermen
>>
>> arch/powerpc/perf/core-book3s.c | 7 +--
>> 1 file changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/arch/powerpc/perf/core-book3s.c
>> b/arch/powerpc/perf/core-book3s.c
>> index 23ec89a59893..55efbba7572b 100644
>> --- a/arch/powerpc/perf/core-book3s.c
>> +++ b/arch/powerpc/perf/core-book3s.c
>> @@ -2254,12 +2254,7 @@ unsigned long perf_instruction_pointer(struct pt_regs
>> *regs)
>> bool use_siar = regs_use_siar(regs);
>> unsigned long siar = mfspr(SPRN_SIAR);
>> - if (ppmu && (ppmu->flags & PPMU_P10_DD1)) {
>> - if (siar)
>> - return siar;
>> - else
>> - return regs->nip;
>> - } else if (use_siar && siar_valid(regs))
>> + if (use_siar && siar_valid(regs) && siar)
>
> You can probably now do
>
> + if (regs_use_siar(regs) && siar_valid(regs) && siar)
>
> and remove use_siar
Hi Christophe,
I will update it. Thanks for pointing it.
Thanks,
Kajol Jain
>
>> return siar + perf_ip_adjust(regs);
>> else
>> return regs->nip;
>>
Re: [PATCH v2 2/2] powerpc/perf: Return regs->nip as instruction pointer value when SIAR is 0
On 8/17/21 11:07 AM, Madhavan Srinivasan wrote: > > On 8/16/21 12:26 PM, Christophe Leroy wrote: >> >> >> Le 16/08/2021 à 08:44, kajoljain a écrit : >>> >>> >>> On 8/14/21 6:14 PM, Michael Ellerman wrote: >>>> Christophe Leroy writes: >>>>> Le 13/08/2021 à 10:24, Kajol Jain a écrit : >>>>>> Incase of random sampling, there can be scenarios where SIAR is not >>>>>> latching sample address and results in 0 value. Since current code >>>>>> directly returning the siar value, we could see multiple instruction >>>>>> pointer values as 0 in perf report. >>>> >>>> Can you please give more detail on that? What scenarios? On what CPUs? >>>> >>> >>> Hi Michael, >>> Sure I will update these details in my next patch-set. >>> >>>>>> Patch resolves this issue by adding a ternary condition to return >>>>>> regs->nip incase SIAR is 0. >>>>> >>>>> Your description seems rather similar to >>>>> https://github.com/linuxppc/linux/commit/2ca13a4cc56c920a6c9fc8ee45d02bccacd7f46c >>>>> >>>>> Does it mean that the problem occurs on more than the power10 DD1 ? >>>>> >>>>> In that case, can the solution be common instead of doing something for >>>>> power10 DD1 and something >>>>> for others ? >>>> >>>> Agreed. >>>> >>>> This change would seem to make that P10 DD1 logic superfluous. >>>> >>>> Also we already have a fallback to regs->nip in the else case of the if, >>>> so we should just use that rather than adding a ternary condition. >>>> >>>> eg. >>>> >>>> if (use_siar && siar_valid(regs) && siar) >>>> return siar + perf_ip_adjust(regs); >>>> else if (use_siar) >>>> return 0; // no valid instruction pointer >>>> else >>>> return regs->nip; >>>> >>>> >>>> I'm also not sure why we have that return 0 case, I can't think of why >>>> we'd ever want to do that rather than using nip. So maybe we should do >>>> another patch to drop that case. >>> >>> Yeah make sense. I will remove return 0 case in my next version. >>> >> >> This was added by commit >> https://github.com/linuxppc/linux/commit/e6878835ac4794f25385522d29c634b7bbb7cca9 >> >> Are we sure it was an error to add it and it can be removed ? > > pc having 0 is wrong (kernel does not execute at 0x0 or userspace). > yeah we should drop it. Hi Madhavan, Sure I will add another patch to drop return 0 condition. Thanks, Kajol jain > > Maddy >> >> Christophe
Re: [PATCH v2 2/2] powerpc/perf: Return regs->nip as instruction pointer value when SIAR is 0
On 8/13/21 3:04 PM, Christophe Leroy wrote:
>
>
> Le 13/08/2021 à 10:24, Kajol Jain a écrit :
>> Incase of random sampling, there can be scenarios where SIAR is not
>> latching sample address and results in 0 value. Since current code
>> directly returning the siar value, we could see multiple instruction
>> pointer values as 0 in perf report.
>> Patch resolves this issue by adding a ternary condition to return
>> regs->nip incase SIAR is 0.
>
> Your description seems rather similar to
> https://github.com/linuxppc/linux/commit/2ca13a4cc56c920a6c9fc8ee45d02bccacd7f46c
>
> Does it mean that the problem occurs on more than the power10 DD1 ?
>
> In that case, can the solution be common instead of doing something for
> power10 DD1 and something for others ?
Hi Christophe,
Yes its better to have common check. I will make these updates.
Thanks,
Kajol Jain
>
>>
>> Fixes: 75382aa72f06 ("powerpc/perf: Move code to select SIAR or pt_regs
>> into perf_read_regs")
>> Signed-off-by: Kajol Jain
>> ---
>> arch/powerpc/perf/core-book3s.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/perf/core-book3s.c
>> b/arch/powerpc/perf/core-book3s.c
>> index 1b464aad29c4..aeecaaf6810f 100644
>> --- a/arch/powerpc/perf/core-book3s.c
>> +++ b/arch/powerpc/perf/core-book3s.c
>> @@ -2260,7 +2260,7 @@ unsigned long perf_instruction_pointer(struct pt_regs
>> *regs)
>> else
>> return regs->nip;
>> } else if (use_siar && siar_valid(regs))
>> - return siar + perf_ip_adjust(regs);
>> + return siar ? siar + perf_ip_adjust(regs) : regs->nip;
>> else if (use_siar)
>> return 0; // no valid instruction pointer
>> else
>>
Re: [PATCH v2 2/2] powerpc/perf: Return regs->nip as instruction pointer value when SIAR is 0
On 8/14/21 6:14 PM, Michael Ellerman wrote: > Christophe Leroy writes: >> Le 13/08/2021 à 10:24, Kajol Jain a écrit : >>> Incase of random sampling, there can be scenarios where SIAR is not >>> latching sample address and results in 0 value. Since current code >>> directly returning the siar value, we could see multiple instruction >>> pointer values as 0 in perf report. > > Can you please give more detail on that? What scenarios? On what CPUs? > Hi Michael, Sure I will update these details in my next patch-set. >>> Patch resolves this issue by adding a ternary condition to return >>> regs->nip incase SIAR is 0. >> >> Your description seems rather similar to >> https://github.com/linuxppc/linux/commit/2ca13a4cc56c920a6c9fc8ee45d02bccacd7f46c >> >> Does it mean that the problem occurs on more than the power10 DD1 ? >> >> In that case, can the solution be common instead of doing something for >> power10 DD1 and something >> for others ? > > Agreed. > > This change would seem to make that P10 DD1 logic superfluous. > > Also we already have a fallback to regs->nip in the else case of the if, > so we should just use that rather than adding a ternary condition. > > eg. > > if (use_siar && siar_valid(regs) && siar) > return siar + perf_ip_adjust(regs); > else if (use_siar) > return 0; // no valid instruction pointer > else > return regs->nip; > > > I'm also not sure why we have that return 0 case, I can't think of why > we'd ever want to do that rather than using nip. So maybe we should do > another patch to drop that case. Yeah make sense. I will remove return 0 case in my next version. Thanks, Kajol Jain > > cheers >
Re: [PATCH v2 1/2] powerpc/perf: Use stack siar instead of mfspr
On 8/14/21 6:00 PM, Michael Ellerman wrote:
> Christophe Leroy writes:
>> Le 13/08/2021 à 10:29, kajoljain a écrit :
>>>
>>> On 8/13/21 1:54 PM, Kajol Jain wrote:
>>>> Minor optimization in the 'perf_instruction_pointer' function code by
>>>> making use of stack siar instead of mfspr.
>>>>
>>>> Fixes: 75382aa72f06 ("powerpc/perf: Move code to select SIAR or pt_regs
>>>> into perf_read_regs")
>>>> Signed-off-by: Kajol Jain
>>>
>>> Please ignore this patch-set as I mentioned wrong version number. I will
>>> resend
>>> this patch-set again with correct version. Sorry for the confusion.
>>
>> I fear you are creating even more confusion by sending a v1 after sending a
>> v2 ...
>
> Yeah in future just reply to the v2 saying "oops I sent v2 instead of
> v1" and leave it at that.
Hi Christophe/Michael,
Sure I will take care next time.
Thanks,
Kajol Jain
>
> cheers
>
Re: [PATCH v2 1/2] powerpc/perf: Use stack siar instead of mfspr
On 8/13/21 1:54 PM, Kajol Jain wrote:
> Minor optimization in the 'perf_instruction_pointer' function code by
> making use of stack siar instead of mfspr.
>
> Fixes: 75382aa72f06 ("powerpc/perf: Move code to select SIAR or pt_regs
> into perf_read_regs")
> Signed-off-by: Kajol Jain
Please ignore this patch-set as I mentioned wrong version number. I will resend
this patch-set again with correct version. Sorry for the confusion.
Thanks,
Kajol Jain
> ---
> arch/powerpc/perf/core-book3s.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index bb0ee716de91..1b464aad29c4 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -2260,7 +2260,7 @@ unsigned long perf_instruction_pointer(struct pt_regs
> *regs)
> else
> return regs->nip;
> } else if (use_siar && siar_valid(regs))
> - return mfspr(SPRN_SIAR) + perf_ip_adjust(regs);
> + return siar + perf_ip_adjust(regs);
> else if (use_siar)
> return 0; // no valid instruction pointer
> else
>
Re: [PATCH v3] fpga: dfl: fme: Fix cpu hotplug issue in performance reporting
On 8/2/21 2:28 PM, Moritz Fischer wrote:
> On Mon, Aug 02, 2021 at 01:15:00PM +0530, kajoljain wrote:
>>
>>
>> On 7/13/21 1:12 PM, Kajol Jain wrote:
>>> The performance reporting driver added cpu hotplug
>>> feature but it didn't add pmu migration call in cpu
>>> offline function.
>>> This can create an issue incase the current designated
>>> cpu being used to collect fme pmu data got offline,
>>> as based on current code we are not migrating fme pmu to
>>> new target cpu. Because of that perf will still try to
>>> fetch data from that offline cpu and hence we will not
>>> get counter data.
>>>
>>> Patch fixed this issue by adding pmu_migrate_context call
>>> in fme_perf_offline_cpu function.
>>>
>>> Fixes: 724142f8c42a ("fpga: dfl: fme: add performance reporting support")
>>> Tested-by: Xu Yilun
>>> Acked-by: Wu Hao
>>> Signed-off-by: Kajol Jain
>>> Cc: sta...@vger.kernel.org
>>> ---
>>
>> Any update on this patch? Please let me know if any changes required.
>>
>> Thanks,
>> Kajol Jain
>
> It's in my 'fixes' branch.
Thanks Moritz for informing me.
Thanks,
Kajol Jain
>
> - Moritz
>
Re: [PATCH v3] fpga: dfl: fme: Fix cpu hotplug issue in performance reporting
On 7/13/21 1:12 PM, Kajol Jain wrote:
> The performance reporting driver added cpu hotplug
> feature but it didn't add pmu migration call in cpu
> offline function.
> This can create an issue incase the current designated
> cpu being used to collect fme pmu data got offline,
> as based on current code we are not migrating fme pmu to
> new target cpu. Because of that perf will still try to
> fetch data from that offline cpu and hence we will not
> get counter data.
>
> Patch fixed this issue by adding pmu_migrate_context call
> in fme_perf_offline_cpu function.
>
> Fixes: 724142f8c42a ("fpga: dfl: fme: add performance reporting support")
> Tested-by: Xu Yilun
> Acked-by: Wu Hao
> Signed-off-by: Kajol Jain
> Cc: sta...@vger.kernel.org
> ---
Any update on this patch? Please let me know if any changes required.
Thanks,
Kajol Jain
> drivers/fpga/dfl-fme-perf.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> ---
> Changelog:
> v2 -> v3:
> - Added Acked-by tag
> - Removed comment as suggested by Wu Hao
> - Link to patch v2: https://lkml.org/lkml/2021/7/9/143
>
> v1 -> v2:
> - Add sta...@vger.kernel.org in cc list
> - Link to patch v1: https://lkml.org/lkml/2021/6/28/275
>
> RFC -> PATCH v1
> - Remove RFC tag
> - Did nits changes on subject and commit message as suggested by Xu Yilun
> - Added Tested-by tag
> - Link to rfc patch: https://lkml.org/lkml/2021/6/28/112
> ---
>
> diff --git a/drivers/fpga/dfl-fme-perf.c b/drivers/fpga/dfl-fme-perf.c
> index 4299145ef347..587c82be12f7 100644
> --- a/drivers/fpga/dfl-fme-perf.c
> +++ b/drivers/fpga/dfl-fme-perf.c
> @@ -953,6 +953,8 @@ static int fme_perf_offline_cpu(unsigned int cpu, struct
> hlist_node *node)
> return 0;
>
> priv->cpu = target;
> + perf_pmu_migrate_context(>pmu, cpu, target);
> +
> return 0;
> }
>
>
Re: [PATCH v7 1/1] powerpc/pseries: Interface to represent PAPR firmware attributes
On 7/23/21 11:16 AM, Pratik R. Sampat wrote: > Adds a generic interface to represent the energy and frequency related > PAPR attributes on the system using the new H_CALL > "H_GET_ENERGY_SCALE_INFO". > > H_GET_EM_PARMS H_CALL was previously responsible for exporting this > information in the lparcfg, however the H_GET_EM_PARMS H_CALL > will be deprecated P10 onwards. > > The H_GET_ENERGY_SCALE_INFO H_CALL is of the following call format: > hcall( > uint64 H_GET_ENERGY_SCALE_INFO, // Get energy scale info > uint64 flags, // Per the flag request > uint64 firstAttributeId,// The attribute id > uint64 bufferAddress, // Guest physical address of the output buffer > uint64 bufferSize // The size in bytes of the output buffer > ); > > This H_CALL can query either all the attributes at once with > firstAttributeId = 0, flags = 0 as well as query only one attribute > at a time with firstAttributeId = id, flags = 1. > > The output buffer consists of the following > 1. number of attributes - 8 bytes > 2. array offset to the data location - 8 bytes > 3. version info - 1 byte > 4. A data array of size num attributes, which contains the following: > a. attribute ID - 8 bytes > b. attribute value in number - 8 bytes > c. attribute name in string - 64 bytes > d. attribute value in string - 64 bytes > > The new H_CALL exports information in direct string value format, hence > a new interface has been introduced in > /sys/firmware/papr/energy_scale_info to export this information to > userspace in an extensible pass-through format. > > The H_CALL returns the name, numeric value and string value (if exists) > > The format of exposing the sysfs information is as follows: > /sys/firmware/papr/energy_scale_info/ >|-- / > |-- desc > |-- value > |-- value_desc (if exists) >|-- / > |-- desc > |-- value > |-- value_desc (if exists) > ... > > The energy information that is exported is useful for userspace tools > such as powerpc-utils. Currently these tools infer the > "power_mode_data" value in the lparcfg, which in turn is obtained from > the to be deprecated H_GET_EM_PARMS H_CALL. > On future platforms, such userspace utilities will have to look at the > data returned from the new H_CALL being populated in this new sysfs > interface and report this information directly without the need of > interpretation. > Patch looks good to me. Reviewed-by: Kajol Jain Thanks, Kajol Jain > Signed-off-by: Pratik R. Sampat > Reviewed-by: Gautham R. Shenoy > --- > .../sysfs-firmware-papr-energy-scale-info | 26 ++ > arch/powerpc/include/asm/hvcall.h | 24 +- > arch/powerpc/kvm/trace_hv.h | 1 + > arch/powerpc/platforms/pseries/Makefile | 3 +- > .../pseries/papr_platform_attributes.c| 312 ++ > 5 files changed, 364 insertions(+), 2 deletions(-) > create mode 100644 > Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info > create mode 100644 arch/powerpc/platforms/pseries/papr_platform_attributes.c > > diff --git a/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info > b/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info > new file mode 100644 > index ..139a576c7c9d > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info > @@ -0,0 +1,26 @@ > +What:/sys/firmware/papr/energy_scale_info > +Date:June 2021 > +Contact: Linux for PowerPC mailing list > +Description: Directory hosting a set of platform attributes like > + energy/frequency on Linux running as a PAPR guest. > + > + Each file in a directory contains a platform > + attribute hierarchy pertaining to performance/ > + energy-savings mode and processor frequency. > + > +What:/sys/firmware/papr/energy_scale_info/ > + /sys/firmware/papr/energy_scale_info//desc > + /sys/firmware/papr/energy_scale_info//value > + /sys/firmware/papr/energy_scale_info//value_desc > +Date:June 2021 > +Contact: Linux for PowerPC mailing list > +Description: Energy, frequency attributes directory for POWERVM servers > + > + This directory provides energy, frequency, folding information. > It > + contains below sysfs attributes: > + > + - desc: String description of the attribute > + > + - value: Numeric value of attribute > + > + - value_desc: String value of attribute > diff --git a/arch/powerpc/include/asm/hvcall.h > b/arch/powerpc/include/asm/hvcall.h > index e3b29eda8074..c91714ea6719 100644 > --- a/arch/powerpc/include/asm/hvcall.h > +++ b/arch/powerpc/include/asm/hvcall.h > @@ -316,7 +316,8 @@ > #define H_SCM_PERFORMANCE_STATS 0x418 > #define H_RPT_INVALIDATE 0x448 > #define H_SCM_FLUSH
Re: [PATCH v6 1/1] powerpc/pseries: Interface to represent PAPR firmware attributes
On 7/20/21 11:04 AM, Pratik R. Sampat wrote: > Adds a generic interface to represent the energy and frequency related > PAPR attributes on the system using the new H_CALL > "H_GET_ENERGY_SCALE_INFO". > > H_GET_EM_PARMS H_CALL was previously responsible for exporting this > information in the lparcfg, however the H_GET_EM_PARMS H_CALL > will be deprecated P10 onwards. > > The H_GET_ENERGY_SCALE_INFO H_CALL is of the following call format: > hcall( > uint64 H_GET_ENERGY_SCALE_INFO, // Get energy scale info > uint64 flags, // Per the flag request > uint64 firstAttributeId,// The attribute id > uint64 bufferAddress, // Guest physical address of the output buffer > uint64 bufferSize // The size in bytes of the output buffer > ); > > This H_CALL can query either all the attributes at once with > firstAttributeId = 0, flags = 0 as well as query only one attribute > at a time with firstAttributeId = id, flags = 1. > > The output buffer consists of the following > 1. number of attributes - 8 bytes > 2. array offset to the data location - 8 bytes > 3. version info - 1 byte > 4. A data array of size num attributes, which contains the following: > a. attribute ID - 8 bytes > b. attribute value in number - 8 bytes > c. attribute name in string - 64 bytes > d. attribute value in string - 64 bytes > > The new H_CALL exports information in direct string value format, hence > a new interface has been introduced in > /sys/firmware/papr/energy_scale_info to export this information to > userspace in an extensible pass-through format. > > The H_CALL returns the name, numeric value and string value (if exists) > > The format of exposing the sysfs information is as follows: > /sys/firmware/papr/energy_scale_info/ >|-- / > |-- desc > |-- value > |-- value_desc (if exists) >|-- / > |-- desc > |-- value > |-- value_desc (if exists) > ... > > The energy information that is exported is useful for userspace tools > such as powerpc-utils. Currently these tools infer the > "power_mode_data" value in the lparcfg, which in turn is obtained from > the to be deprecated H_GET_EM_PARMS H_CALL. > On future platforms, such userspace utilities will have to look at the > data returned from the new H_CALL being populated in this new sysfs > interface and report this information directly without the need of > interpretation. > > Signed-off-by: Pratik R. Sampat > Reviewed-by: Gautham R. Shenoy > --- > .../sysfs-firmware-papr-energy-scale-info | 26 ++ > arch/powerpc/include/asm/hvcall.h | 24 +- > arch/powerpc/kvm/trace_hv.h | 1 + > arch/powerpc/platforms/pseries/Makefile | 3 +- > .../pseries/papr_platform_attributes.c| 312 ++ > 5 files changed, 364 insertions(+), 2 deletions(-) > create mode 100644 > Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info > create mode 100644 arch/powerpc/platforms/pseries/papr_platform_attributes.c > > diff --git a/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info > b/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info > new file mode 100644 > index ..139a576c7c9d > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info > @@ -0,0 +1,26 @@ > +What:/sys/firmware/papr/energy_scale_info > +Date:June 2021 > +Contact: Linux for PowerPC mailing list > +Description: Directory hosting a set of platform attributes like > + energy/frequency on Linux running as a PAPR guest. > + > + Each file in a directory contains a platform > + attribute hierarchy pertaining to performance/ > + energy-savings mode and processor frequency. > + > +What:/sys/firmware/papr/energy_scale_info/ > + /sys/firmware/papr/energy_scale_info//desc > + /sys/firmware/papr/energy_scale_info//value > + /sys/firmware/papr/energy_scale_info//value_desc > +Date:June 2021 > +Contact: Linux for PowerPC mailing list > +Description: Energy, frequency attributes directory for POWERVM servers > + > + This directory provides energy, frequency, folding information. > It > + contains below sysfs attributes: > + > + - desc: String description of the attribute > + > + - value: Numeric value of attribute > + > + - value_desc: String value of attribute > diff --git a/arch/powerpc/include/asm/hvcall.h > b/arch/powerpc/include/asm/hvcall.h > index e3b29eda8074..c91714ea6719 100644 > --- a/arch/powerpc/include/asm/hvcall.h > +++ b/arch/powerpc/include/asm/hvcall.h > @@ -316,7 +316,8 @@ > #define H_SCM_PERFORMANCE_STATS 0x418 > #define H_RPT_INVALIDATE 0x448 > #define H_SCM_FLUSH 0x44C > -#define MAX_HCALL_OPCODE H_SCM_FLUSH > +#define
Re: [PATCH v2] fpga: dfl: fme: Fix cpu hotplug issue in performance reporting
On 7/12/21 7:57 AM, Wu, Hao wrote:
>> Subject: [PATCH v2] fpga: dfl: fme: Fix cpu hotplug issue in performance
>> reporting
>>
>> The performance reporting driver added cpu hotplug
>> feature but it didn't add pmu migration call in cpu
>> offline function.
>> This can create an issue incase the current designated
>> cpu being used to collect fme pmu data got offline,
>> as based on current code we are not migrating fme pmu to
>> new target cpu. Because of that perf will still try to
>> fetch data from that offline cpu and hence we will not
>> get counter data.
>>
>> Patch fixed this issue by adding pmu_migrate_context call
>> in fme_perf_offline_cpu function.
>>
>> Fixes: 724142f8c42a ("fpga: dfl: fme: add performance reporting support")
>> Tested-by: Xu Yilun
>> Signed-off-by: Kajol Jain
>
> Thanks for this fixing! And thanks Yilun for the verification too. : )
>
>> Cc: sta...@vger.kernel.org
>> ---
>> drivers/fpga/dfl-fme-perf.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> ---
>> Changelog:
>> v1 -> v2:
>> - Add sta...@vger.kernel.org in cc list
>>
>> RFC -> PATCH v1
>> - Remove RFC tag
>> - Did nits changes on subject and commit message as suggested by Xu Yilun
>> - Added Tested-by tag
>> - Link to rfc patch: https://lkml.org/lkml/2021/6/28/112
>> ---
>> diff --git a/drivers/fpga/dfl-fme-perf.c b/drivers/fpga/dfl-fme-perf.c
>> index 4299145ef347..b9a54583e505 100644
>> --- a/drivers/fpga/dfl-fme-perf.c
>> +++ b/drivers/fpga/dfl-fme-perf.c
>> @@ -953,6 +953,10 @@ static int fme_perf_offline_cpu(unsigned int cpu, struct
>> hlist_node *node)
>> return 0;
>>
>> priv->cpu = target;
>> +
>> +/* Migrate fme_perf pmu events to the new target cpu */
>
> Only one minor item, this line is not needed. : )
>
> After remove it,
> Acked-by: Wu Hao
Hi Wu Hao,
Sure I will remove this comment and send new patch.
Thanks,
Kajol Jain
>
> Thanks
> Hao
>
>> +perf_pmu_migrate_context(>pmu, cpu, target);
>> +
>> return 0;
>> }
>>
>> --
>> 2.31.1
>
Re: [PATCH] perf script python: Fix buffer size to report iregs in perf script
On 7/7/21 12:45 AM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Jul 06, 2021 at 05:26:12PM +0530, kajoljain escreveu:
>>
>>
>> On 6/29/21 12:39 PM, kajoljain wrote:
>>>
>>>
>>> On 6/28/21 8:19 PM, Paul A. Clarke wrote:
>>>> On Mon, Jun 28, 2021 at 11:53:41AM +0530, Kajol Jain wrote:
>>>>> Commit 48a1f565261d ("perf script python: Add more PMU fields
>>>>> to event handler dict") added functionality to report fields like
>>>>> weight, iregs, uregs etc via perf report.
>>>>> That commit predefined buffer size to 512 bytes to print those fields.
>>>>>
>>>>> But incase of powerpc, since we added extended regs support
>>>>> in commits:
>>>>>
>>>>> Commit 068aeea3773a ("perf powerpc: Support exposing Performance Monitor
>>>>> Counter SPRs as part of extended regs")
>>>>> Commit d735599a069f ("powerpc/perf: Add extended regs support for
>>>>> power10 platform")
>>>>>
>>>>> Now iregs can carry more bytes of data and this predefined buffer size
>>>>> can result to data loss in perf script output.
>>>>>
>>>>> Patch resolve this issue by making buffer size dynamic based on number
>>>>> of registers needed to print. It also changed return type for function
>>>>> "regs_map" from int to void, as the return value is not being used by
>>>>> the caller function "set_regs_in_dict".
>>>>>
>>>>> Fixes: 068aeea3773a ("perf powerpc: Support exposing Performance Monitor
>>>>> Counter SPRs as part of extended regs")
>>>>> Signed-off-by: Kajol Jain
>>>>> ---
>>>>> .../util/scripting-engines/trace-event-python.c | 17 -
>>>>> 1 file changed, 12 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/tools/perf/util/scripting-engines/trace-event-python.c
>>>>> b/tools/perf/util/scripting-engines/trace-event-python.c
>>>>> index 4e4aa4c97ac5..c8c9706b4643 100644
>>>>> --- a/tools/perf/util/scripting-engines/trace-event-python.c
>>>>> +++ b/tools/perf/util/scripting-engines/trace-event-python.c
>>>> [...]
>>>>> @@ -713,7 +711,16 @@ static void set_regs_in_dict(PyObject *dict,
>>>>>struct evsel *evsel)
>>>>> {
>>>>> struct perf_event_attr *attr = >core.attr;
>>>>> - char bf[512];
>>>>> +
>>>>> + /*
>>>>> + * Here value 28 is a constant size which can be used to print
>>>>> + * one register value and its corresponds to:
>>>>> + * 16 chars is to specify 64 bit register in hexadecimal.
>>>>> + * 2 chars is for appending "0x" to the hexadecimal value and
>>>>> + * 10 chars is for register name.
>>>>> + */
>>>>> + int size = __sw_hweight64(attr->sample_regs_intr) * 28;
>>>>> + char bf[size];
>>>>
>>>> I propose using a template rather than a magic number here. Something like:
>>>> const char reg_name_tmpl[] = "10 chars ";
>>>> const char reg_value_tmpl[] = "0x0123456789abcdef";
>>>> const int size = __sw_hweight64(attr->sample_regs_intr) +
>>>> sizeof reg_name_tmpl + sizeof reg_value_tmpl;
>>>>
>>>
>>> Hi Paul,
>>>Thanks for reviewing the patch. Yes these are
>>> some standardization we can do by creating macros for different
>>> fields.
>>> The basic idea is, we want to provide significant buffer size
>>> based on number of registers present in sample_regs_intr to accommodate
>>> all data.
>>>
>>
>> Hi Arnaldo/Jiri,
>>Is the approach used in this patch looks fine to you?
>
> Yeah, and the comment you provide right above it explains it, so I think
> that is enough, ok?
>
Hi Arnaldo,
Thanks for reviewing it. As you said added comment already explains
why we are taking size constant as 28, should we skip adding macros part?
Can you pull this patch.
Thanks,
Kajol Jain
> - Arnaldo
>
>> Thanks,
>> Kajol Jain
>>
>>> But before going to optimizing code, Arnaldo/Jiri, is this approach looks
>>> good to you?
>>>
>>>> Pardon my ignorance, but is there no separation/whitespace between the name
>>>> and the value?
>>>
>>> This is how we will get data via perf script
>>>
>>> r0:0xc0112008
>>> r1:0xc00023b37920
>>> r2:0xc144c900
>>> r3:0xc000bc566120
>>> r4:0xc000c560
>>> r5:0x2606c6506ca
>>> r6:0xc00023b378f8
>>> r7:0xfd9f93a48f0e
>>> .
>>>
>>> And is there some significance to 10 characters for the
>>>> register name, or is that a magic number?
>>>
>>> Most of the register name are within 10 characters, basically we are giving
>>> this
>>> magic number to make sure we have enough space in buffer to contain all
>>> registers
>>> name with colon.
>>>
>>> Thanks,
>>> Kajol Jain
>>>
>>>>
>>>> PC
>>>>
>
Re: [PATCH] perf script python: Fix buffer size to report iregs in perf script
On 6/29/21 12:39 PM, kajoljain wrote:
>
>
> On 6/28/21 8:19 PM, Paul A. Clarke wrote:
>> On Mon, Jun 28, 2021 at 11:53:41AM +0530, Kajol Jain wrote:
>>> Commit 48a1f565261d ("perf script python: Add more PMU fields
>>> to event handler dict") added functionality to report fields like
>>> weight, iregs, uregs etc via perf report.
>>> That commit predefined buffer size to 512 bytes to print those fields.
>>>
>>> But incase of powerpc, since we added extended regs support
>>> in commits:
>>>
>>> Commit 068aeea3773a ("perf powerpc: Support exposing Performance Monitor
>>> Counter SPRs as part of extended regs")
>>> Commit d735599a069f ("powerpc/perf: Add extended regs support for
>>> power10 platform")
>>>
>>> Now iregs can carry more bytes of data and this predefined buffer size
>>> can result to data loss in perf script output.
>>>
>>> Patch resolve this issue by making buffer size dynamic based on number
>>> of registers needed to print. It also changed return type for function
>>> "regs_map" from int to void, as the return value is not being used by
>>> the caller function "set_regs_in_dict".
>>>
>>> Fixes: 068aeea3773a ("perf powerpc: Support exposing Performance Monitor
>>> Counter SPRs as part of extended regs")
>>> Signed-off-by: Kajol Jain
>>> ---
>>> .../util/scripting-engines/trace-event-python.c | 17 -
>>> 1 file changed, 12 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/tools/perf/util/scripting-engines/trace-event-python.c
>>> b/tools/perf/util/scripting-engines/trace-event-python.c
>>> index 4e4aa4c97ac5..c8c9706b4643 100644
>>> --- a/tools/perf/util/scripting-engines/trace-event-python.c
>>> +++ b/tools/perf/util/scripting-engines/trace-event-python.c
>> [...]
>>> @@ -713,7 +711,16 @@ static void set_regs_in_dict(PyObject *dict,
>>> struct evsel *evsel)
>>> {
>>> struct perf_event_attr *attr = >core.attr;
>>> - char bf[512];
>>> +
>>> + /*
>>> +* Here value 28 is a constant size which can be used to print
>>> +* one register value and its corresponds to:
>>> +* 16 chars is to specify 64 bit register in hexadecimal.
>>> +* 2 chars is for appending "0x" to the hexadecimal value and
>>> +* 10 chars is for register name.
>>> +*/
>>> + int size = __sw_hweight64(attr->sample_regs_intr) * 28;
>>> + char bf[size];
>>
>> I propose using a template rather than a magic number here. Something like:
>> const char reg_name_tmpl[] = "10 chars ";
>> const char reg_value_tmpl[] = "0x0123456789abcdef";
>> const int size = __sw_hweight64(attr->sample_regs_intr) +
>> sizeof reg_name_tmpl + sizeof reg_value_tmpl;
>>
>
> Hi Paul,
>Thanks for reviewing the patch. Yes these are
> some standardization we can do by creating macros for different
> fields.
> The basic idea is, we want to provide significant buffer size
> based on number of registers present in sample_regs_intr to accommodate
> all data.
>
Hi Arnaldo/Jiri,
Is the approach used in this patch looks fine to you?
Thanks,
Kajol Jain
> But before going to optimizing code, Arnaldo/Jiri, is this approach looks
> good to you?
>
>> Pardon my ignorance, but is there no separation/whitespace between the name
>> and the value?
>
> This is how we will get data via perf script
>
> r0:0xc0112008
> r1:0xc00023b37920
> r2:0xc144c900
> r3:0xc000bc566120
> r4:0xc000c560
> r5:0x2606c6506ca
> r6:0xc00023b378f8
> r7:0xfd9f93a48f0e
> .
>
> And is there some significance to 10 characters for the
>> register name, or is that a magic number?
>
> Most of the register name are within 10 characters, basically we are giving
> this
> magic number to make sure we have enough space in buffer to contain all
> registers
> name with colon.
>
> Thanks,
> Kajol Jain
>
>>
>> PC
>>
Re: [PATCH v3 0/4] Add perf interface to expose nvdimm
On 6/23/21 4:46 PM, Michael Ellerman wrote: > Peter Zijlstra writes: >> On Wed, Jun 23, 2021 at 01:40:38PM +0530, kajoljain wrote: >>> >>> On 6/22/21 6:44 PM, Peter Zijlstra wrote: >>>> On Thu, Jun 17, 2021 at 06:56:13PM +0530, Kajol Jain wrote: >>>>> --- >>>>> Kajol Jain (4): >>>>> drivers/nvdimm: Add nvdimm pmu structure >>>>> drivers/nvdimm: Add perf interface to expose nvdimm performance stats >>>>> powerpc/papr_scm: Add perf interface support >>>>> powerpc/papr_scm: Document papr_scm sysfs event format entries >>>> >>>> Don't see anything obviously wrong with this one. >>>> >>>> Acked-by: Peter Zijlstra (Intel) >>>> >>> >>> Hi Peter, >>> Thanks for reviewing the patch. Can you help me on how to take >>> these patches to linus tree or can you take it? >> >> I would expect either the NVDIMM or PPC maintainers to take this. Dan, >> Michael ? > > I can take it but would need Acks from nvdimm folks. Hi Dan, Do you have any comments on this patchset. Please let me know. Thanks, Kajol jain > > cheers >
Re: [PATCH] fpga: dfl: fme: Fix cpu hotplug issue in performance reporting
On 6/29/21 12:57 PM, Greg KH wrote: > On Tue, Jun 29, 2021 at 12:45:20PM +0530, kajoljain wrote: >> >> >> On 6/28/21 3:47 PM, Kajol Jain wrote: >>> The performance reporting driver added cpu hotplug >>> feature but it didn't add pmu migration call in cpu >>> offline function. >>> This can create an issue incase the current designated >>> cpu being used to collect fme pmu data got offline, >>> as based on current code we are not migrating fme pmu to >>> new target cpu. Because of that perf will still try to >>> fetch data from that offline cpu and hence we will not >>> get counter data. >>> >>> Patch fixed this issue by adding pmu_migrate_context call >>> in fme_perf_offline_cpu function. >>> >> >> Adding sta...@vger.kernel.org in cc list as suggested by Moritz Fischer. > > > > > This is not the correct way to submit patches for inclusion in the > stable kernel tree. Please read: > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html > for how to do this properly. Thanks Greg for pointing it, I will take care in my next version. Thanks, Kajol Jain > > >
Re: [PATCH] fpga: dfl: fme: Fix cpu hotplug issue in performance reporting
On 6/28/21 3:47 PM, Kajol Jain wrote:
> The performance reporting driver added cpu hotplug
> feature but it didn't add pmu migration call in cpu
> offline function.
> This can create an issue incase the current designated
> cpu being used to collect fme pmu data got offline,
> as based on current code we are not migrating fme pmu to
> new target cpu. Because of that perf will still try to
> fetch data from that offline cpu and hence we will not
> get counter data.
>
> Patch fixed this issue by adding pmu_migrate_context call
> in fme_perf_offline_cpu function.
>
Adding sta...@vger.kernel.org in cc list as suggested by Moritz Fischer.
Thanks,
Kajol Jain
> Fixes: 724142f8c42a ("fpga: dfl: fme: add performance reporting support")
> Tested-by: Xu Yilun
> Signed-off-by: Kajol Jain
> ---
> drivers/fpga/dfl-fme-perf.c | 4
> 1 file changed, 4 insertions(+)
>
> ---
> Changelog:
> - Remove RFC tag
> - Did nits changes on subject and commit message as suggested by Xu Yilun
> - Added Tested-by tag
> - Link to rfc patch: https://lkml.org/lkml/2021/6/28/112
> ---
> diff --git a/drivers/fpga/dfl-fme-perf.c b/drivers/fpga/dfl-fme-perf.c
> index 4299145ef347..b9a54583e505 100644
> --- a/drivers/fpga/dfl-fme-perf.c
> +++ b/drivers/fpga/dfl-fme-perf.c
> @@ -953,6 +953,10 @@ static int fme_perf_offline_cpu(unsigned int cpu, struct
> hlist_node *node)
> return 0;
>
> priv->cpu = target;
> +
> + /* Migrate fme_perf pmu events to the new target cpu */
> + perf_pmu_migrate_context(>pmu, cpu, target);
> +
> return 0;
> }
>
>
Re: [RFC] fpga: dfl: fme: Fix cpu hotplug code
On 6/29/21 12:10 AM, Moritz Fischer wrote:
> On Mon, Jun 28, 2021 at 12:45:46PM +0530, Kajol Jain wrote:
>> Commit 724142f8c42a ("fpga: dfl: fme: add performance
>> reporting support") added performance reporting support
>> for FPGA management engine via perf.
>>
>> It also added cpu hotplug feature but it didn't add
>> pmu migration call in cpu offline function.
>> This can create an issue incase the current designated
>> cpu being used to collect fme pmu data got offline,
>> as based on current code we are not migrating fme pmu to
>> new target cpu. Because of that perf will still try to
>> fetch data from that offline cpu and hence we will not
>> get counter data.
>>
>> Patch fixed this issue by adding pmu_migrate_context call
>> in fme_perf_offline_cpu function.
>>
>> Fixes: 724142f8c42a ("fpga: dfl: fme: add performance reporting support")
>> Signed-off-by: Kajol Jain
>
> You might want to Cc: sta...@vger.kernel.org if it fixes an actual bug.
Hi Moritz,
I already send patch out without RFC tag yesterday.
Link to the patch: https://lkml.org/lkml/2021/6/28/275
I will cc sta...@vger.kernel.org there as suggested by you.
Thanks,
Kajol Jain
>> ---
>> drivers/fpga/dfl-fme-perf.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> ---
>> - This fix patch is not tested (as I don't have required environment).
>> But issue mentioned in the commit msg can be re-created, by starting any
>> fme_perf event and while its still running, offline current designated
>> cpu pointed by cpumask file. Since current code didn't migrating pmu,
>> perf gonna try getting counts from that offlined cpu and hence we will
>> not get event data.
>> ---
>> diff --git a/drivers/fpga/dfl-fme-perf.c b/drivers/fpga/dfl-fme-perf.c
>> index 4299145ef347..b9a54583e505 100644
>> --- a/drivers/fpga/dfl-fme-perf.c
>> +++ b/drivers/fpga/dfl-fme-perf.c
>> @@ -953,6 +953,10 @@ static int fme_perf_offline_cpu(unsigned int cpu,
>> struct hlist_node *node)
>> return 0;
>>
>> priv->cpu = target;
>> +
>> +/* Migrate fme_perf pmu events to the new target cpu */
>> +perf_pmu_migrate_context(>pmu, cpu, target);
>> +
>> return 0;
>> }
>>
>> --
>> 2.31.1
>>
> - Moritz
>
Re: [PATCH] perf script python: Fix buffer size to report iregs in perf script
On 6/28/21 8:19 PM, Paul A. Clarke wrote:
> On Mon, Jun 28, 2021 at 11:53:41AM +0530, Kajol Jain wrote:
>> Commit 48a1f565261d ("perf script python: Add more PMU fields
>> to event handler dict") added functionality to report fields like
>> weight, iregs, uregs etc via perf report.
>> That commit predefined buffer size to 512 bytes to print those fields.
>>
>> But incase of powerpc, since we added extended regs support
>> in commits:
>>
>> Commit 068aeea3773a ("perf powerpc: Support exposing Performance Monitor
>> Counter SPRs as part of extended regs")
>> Commit d735599a069f ("powerpc/perf: Add extended regs support for
>> power10 platform")
>>
>> Now iregs can carry more bytes of data and this predefined buffer size
>> can result to data loss in perf script output.
>>
>> Patch resolve this issue by making buffer size dynamic based on number
>> of registers needed to print. It also changed return type for function
>> "regs_map" from int to void, as the return value is not being used by
>> the caller function "set_regs_in_dict".
>>
>> Fixes: 068aeea3773a ("perf powerpc: Support exposing Performance Monitor
>> Counter SPRs as part of extended regs")
>> Signed-off-by: Kajol Jain
>> ---
>> .../util/scripting-engines/trace-event-python.c | 17 -
>> 1 file changed, 12 insertions(+), 5 deletions(-)
>>
>> diff --git a/tools/perf/util/scripting-engines/trace-event-python.c
>> b/tools/perf/util/scripting-engines/trace-event-python.c
>> index 4e4aa4c97ac5..c8c9706b4643 100644
>> --- a/tools/perf/util/scripting-engines/trace-event-python.c
>> +++ b/tools/perf/util/scripting-engines/trace-event-python.c
> [...]
>> @@ -713,7 +711,16 @@ static void set_regs_in_dict(PyObject *dict,
>> struct evsel *evsel)
>> {
>> struct perf_event_attr *attr = >core.attr;
>> -char bf[512];
>> +
>> +/*
>> + * Here value 28 is a constant size which can be used to print
>> + * one register value and its corresponds to:
>> + * 16 chars is to specify 64 bit register in hexadecimal.
>> + * 2 chars is for appending "0x" to the hexadecimal value and
>> + * 10 chars is for register name.
>> + */
>> +int size = __sw_hweight64(attr->sample_regs_intr) * 28;
>> +char bf[size];
>
> I propose using a template rather than a magic number here. Something like:
> const char reg_name_tmpl[] = "10 chars ";
> const char reg_value_tmpl[] = "0x0123456789abcdef";
> const int size = __sw_hweight64(attr->sample_regs_intr) +
> sizeof reg_name_tmpl + sizeof reg_value_tmpl;
>
Hi Paul,
Thanks for reviewing the patch. Yes these are
some standardization we can do by creating macros for different
fields.
The basic idea is, we want to provide significant buffer size
based on number of registers present in sample_regs_intr to accommodate
all data.
But before going to optimizing code, Arnaldo/Jiri, is this approach looks good
to you?
> Pardon my ignorance, but is there no separation/whitespace between the name
> and the value?
This is how we will get data via perf script
r0:0xc0112008
r1:0xc00023b37920
r2:0xc144c900
r3:0xc000bc566120
r4:0xc000c560
r5:0x2606c6506ca
r6:0xc00023b378f8
r7:0xfd9f93a48f0e
.
And is there some significance to 10 characters for the
> register name, or is that a magic number?
Most of the register name are within 10 characters, basically we are giving this
magic number to make sure we have enough space in buffer to contain all
registers
name with colon.
Thanks,
Kajol Jain
>
> PC
>
Re: [RFC] fpga: dfl: fme: Fix cpu hotplug code
On 6/28/21 2:31 PM, Xu Yilun wrote:
> It's a good fix, you can drop the RFC in commit title. :)
>
> The title could be more specific, like:
>
> fpga: dfl: fme: Fix cpu hotplug issue in performance reporting
>
> So we know it is for performance reporting feature at first glance.
>
> On Mon, Jun 28, 2021 at 12:45:46PM +0530, Kajol Jain wrote:
>
>> Commit 724142f8c42a ("fpga: dfl: fme: add performance
>> reporting support") added performance reporting support
>> for FPGA management engine via perf.
>
> May drop this section, it is indicated in the Fixes tag.
>
Hi Yilun,
Thanks for testing the patch. I will make mentioned changes and send
new patch.
Thanks,
Kajol Jain
>>
>> It also added cpu hotplug feature but it didn't add
>
> The performance reporting driver added cpu hotplug ...
>
>> pmu migration call in cpu offline function.
>> This can create an issue incase the current designated
>> cpu being used to collect fme pmu data got offline,
>> as based on current code we are not migrating fme pmu to
>> new target cpu. Because of that perf will still try to
>> fetch data from that offline cpu and hence we will not
>> get counter data.
>>
>> Patch fixed this issue by adding pmu_migrate_context call
>> in fme_perf_offline_cpu function.
>>
>> Fixes: 724142f8c42a ("fpga: dfl: fme: add performance reporting support")
>> Signed-off-by: Kajol Jain
>
> Tested-by: Xu Yilun
>
> Thanks,
> Yilun
>
>> ---
>> drivers/fpga/dfl-fme-perf.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> ---
>> - This fix patch is not tested (as I don't have required environment).
>> But issue mentioned in the commit msg can be re-created, by starting any
>> fme_perf event and while its still running, offline current designated
>> cpu pointed by cpumask file. Since current code didn't migrating pmu,
>> perf gonna try getting counts from that offlined cpu and hence we will
>> not get event data.
>> ---
>> diff --git a/drivers/fpga/dfl-fme-perf.c b/drivers/fpga/dfl-fme-perf.c
>> index 4299145ef347..b9a54583e505 100644
>> --- a/drivers/fpga/dfl-fme-perf.c
>> +++ b/drivers/fpga/dfl-fme-perf.c
>> @@ -953,6 +953,10 @@ static int fme_perf_offline_cpu(unsigned int cpu,
>> struct hlist_node *node)
>> return 0;
>>
>> priv->cpu = target;
>> +
>> +/* Migrate fme_perf pmu events to the new target cpu */
>> +perf_pmu_migrate_context(>pmu, cpu, target);
>> +
>> return 0;
>> }
>>
>> --
>> 2.31.1
Re: [PATCH] perf vendor events power10: Adds 24x7 nest metric events for power10 platform
On 6/25/21 6:51 PM, Paul A. Clarke wrote:
> On Fri, Jun 25, 2021 at 05:29:48PM +0530, Kajol Jain wrote:
>> Patch adds 24x7 nest metric events for POWER10.
>>
>> Signed-off-by: Kajol Jain
>> ---
>> .../arch/powerpc/power10/nest_metrics.json| 491 ++
>> 1 file changed, 491 insertions(+)
>> create mode 100644
>> tools/perf/pmu-events/arch/powerpc/power10/nest_metrics.json
>>
>> diff --git a/tools/perf/pmu-events/arch/powerpc/power10/nest_metrics.json
>> b/tools/perf/pmu-events/arch/powerpc/power10/nest_metrics.json
>> new file mode 100644
>> index ..b79046cd8b09
>> --- /dev/null
>> +++ b/tools/perf/pmu-events/arch/powerpc/power10/nest_metrics.json
>> @@ -0,0 +1,491 @@
>> +[
>> +{
>> + "MetricName": "VEC_GROUP_PUMP_RETRY_RATIO_P01",
>> + "BriefDescription": "VEC_GROUP_PUMP_RETRY_RATIO_P01",
>
> Is it possible to get better descriptions than just a restatement of the
> name, or no description at all?
>
> This comment obviously applies to almost all of the metrics herein.
Hi Paul,
Thanks for reviewing the patch. Sure I will remove description part for now.
>
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_VG_PUMP01\\,chip\\=?@ /
>> hv_24x7@PM_PB_VG_PUMP01\\,chip\\=?@) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> +},
>> +{
>> + "MetricName": "VEC_GROUP_PUMP_RETRY_RATIO_P23",
>> + "BriefDescription": "VEC_GROUP_PUMP_RETRY_RATIO_P23",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_VG_PUMP23\\,chip\\=?@ /
>> hv_24x7@PM_PB_VG_PUMP23\\,chip\\=?@) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> +},
>> +{
>> + "MetricName": "LOCAL_NODE_PUMP_RETRY_RATIO_P01",
>> + "BriefDescription": "LOCAL_NODE_PUMP_RETRY_RATIO_P01",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_LNS_PUMP01\\,chip\\=?@ /
>> hv_24x7@PM_PB_LNS_PUMP01\\,chip\\=?@) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> +},
>> +{
>> + "MetricName": "LOCAL_NODE_PUMP_RETRY_RATIO_P23",
>> + "BriefDescription": "LOCAL_NODE_PUMP_RETRY_RATIO_P23",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_LNS_PUMP23\\,chip\\=?@ /
>> hv_24x7@PM_PB_LNS_PUMP23\\,chip\\=?@) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> +},
>> +{
>> + "MetricName": "GROUP_PUMP_RETRY_RATIO_P01",
>> + "BriefDescription": "GROUP_PUMP_RETRY_RATIO_P01",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_GROUP_PUMP01\\,chip\\=?@ /
>> hv_24x7@PM_PB_GROUP_PUMP01\\,chip\\=?@) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> +},
>> +{
>> + "MetricName": "GROUP_PUMP_RETRY_RATIO_P23",
>> + "BriefDescription": "GROUP_PUMP_RETRY_RATIO_P23",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_GROUP_PUMP23\\,chip\\=?@ /
>> hv_24x7@PM_PB_GROUP_PUMP23\\,chip\\=?@) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> +},
>> +{
>> + "MetricName": "TOTAL_GROUP_PUMPS_P01",
>> + "BriefDescription": "TOTAL_GROUP_PUMPS_P01(PER-CYC)",
>> + "MetricExpr": "(hv_24x7@PM_PB_GROUP_PUMP01\\,chip\\=?@ /
>> hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
>> + "ScaleUnit": "4",
>> + "AggregationMode": "PerChip"
>> +},
>> +{
>> + "MetricName": "TOTAL_GROUP_PUMPS_P23",
>> + "BriefDescription": "TOTAL_GROUP_PUMPS_P23(PER-CYC)",
>> + "MetricExpr": "(hv_24x7@PM_PB_GROUP_PUMP23\\,chip\\=?@ /
>> hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
>> + "ScaleUnit": "4",
>> + "AggregationMode": "PerChip"
>> +},
>> +{
>> + "MetricName": "TOTAL_GROUP_PUMPS_RETRIES_P01",
>> + "BriefDescription": "TOTAL_GROUP_PUMPS_RETRIES_P01(PER-CYC)",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_GROUP_PUMP01\\,chip\\=?@ /
>> hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
>> + "ScaleUnit": "4",
>> + "AggregationMode": "PerChip"
>> +},
>> +{
>> + "MetricName": "TOTAL_GROUP_PUMPS_RETRIES_P23",
>> + "BriefDescription": "TOTAL_GROUP_PUMPS_RETRIES_P23(PER-CYC)",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_GROUP_PUMP23\\,chip\\=?@ /
>> hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
>> + "ScaleUnit": "4",
>> + "AggregationMode": "PerChip"
>> +},
>> +{
>> + "MetricName": "REMOTE_NODE_PUMPS_RETRIES_RATIO_P01",
>> + "BriefDescription": "REMOTE_NODE_PUMPS_RETRIES_RATIO_P01",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_RNS_PUMP01\\,chip\\=?@ /
>> hv_24x7@PM_PB_RNS_PUMP01\\,chip\\=?@) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> +},
>> +{
>> + "MetricName": "REMOTE_NODE_PUMPS_RETRIES_RATIO_P23",
>> + "BriefDescription": "REMOTE_NODE_PUMPS_RETRIES_RATIO_P23",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_RNS_PUMP23\\,chip\\=?@ /
>> hv_24x7@PM_PB_RNS_PUMP23\\,chip\\=?@) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> +},
>> +{
>> + "MetricName": "TOTAL_VECTOR_GROUP_PUMPS_P01",
>> +
Re: [PATCH v3 0/4] Add perf interface to expose nvdimm
On 6/22/21 6:44 PM, Peter Zijlstra wrote: > On Thu, Jun 17, 2021 at 06:56:13PM +0530, Kajol Jain wrote: >> --- >> Kajol Jain (4): >> drivers/nvdimm: Add nvdimm pmu structure >> drivers/nvdimm: Add perf interface to expose nvdimm performance stats >> powerpc/papr_scm: Add perf interface support >> powerpc/papr_scm: Document papr_scm sysfs event format entries > > Don't see anything obviously wrong with this one. > > Acked-by: Peter Zijlstra (Intel) > Hi Peter, Thanks for reviewing the patch. Can you help me on how to take these patches to linus tree or can you take it? Thanks, Kajol Jain
Re: [PATCH v2 0/4] Add perf interface to expose nvdimm
On 6/16/21 4:25 PM, Nageswara Sastry wrote: > > >> On 14-Jun-2021, at 10:53 AM, Kajol Jain wrote: >> >> Patchset adds performance stats reporting support for nvdimm. >> Added interface includes support for pmu register/unregister >> functions. A structure is added called nvdimm_pmu to be used for >> adding arch/platform specific data such as supported events, cpumask >> pmu event functions like event_init/add/read/del. >> User could use the standard perf tool to access perf >> events exposed via pmu. >> >> Added implementation to expose IBM pseries platform nmem* >> device performance stats using this interface. >> ... >> >> Patch1: >>Introduces the nvdimm_pmu structure >> Patch2: >> Adds common interface to add arch/platform specific data >> includes supported events, pmu event functions. It also >> adds code for cpu hotplug support. >> Patch3: >>Add code in arch/powerpc/platform/pseries/papr_scm.c to expose >>nmem* pmu. It fills in the nvdimm_pmu structure with event attrs >>cpumask andevent functions and then registers the pmu by adding >>callbacks to register_nvdimm_pmu. >> Patch4: >>Sysfs documentation patch > > Tested with the following scenarios: > 1. Check dmesg for nmem PMU registered messages. > 2. Listed nmem events using 'perf list and perf list nmem' > 3. Ran 'perf stat' with single event, grouping events, events from same pmu, >different pmu and invalid events > 4. Read from sysfs files, Writing in to sysfs files > 5. While running nmem events with perf stat, offline cpu from the > nmem?/cpumask > > While running the above functionality worked as expected, no error messages > seen > in dmesg. > > Tested-by: Nageswara R Sastry Hi Nageswara, Thanks for testing the patch-set. There is a nit change which need to be done in patch 4(Documentation patch). We need to update nvdimm mailing list from linux-nvd...@lists.01.org to nvd...@lists.linux.dev. I will make this change and send a new patch-set with your tested-by tag. Thanks, Kajol Jain > >> >> Changelog >> --- >> PATCH v1 -> PATCH v2 >> - Fix hotplug code by adding pmu migration call >> incase current designated cpu got offline. As >> pointed by Peter Zijlstra. >> >> - Removed the retun -1 part from cpu hotplug offline >> function. >> >> - Link to the previous patchset : https://lkml.org/lkml/2021/6/8/500 >> --- >> Kajol Jain (4): >> drivers/nvdimm: Add nvdimm pmu structure >> drivers/nvdimm: Add perf interface to expose nvdimm performance stats >> powerpc/papr_scm: Add perf interface support >> powerpc/papr_scm: Document papr_scm sysfs event format entries >> >> Documentation/ABI/testing/sysfs-bus-papr-pmem | 31 ++ >> arch/powerpc/include/asm/device.h | 5 + >> arch/powerpc/platforms/pseries/papr_scm.c | 365 ++ >> drivers/nvdimm/Makefile | 1 + >> drivers/nvdimm/nd_perf.c | 230 +++ >> include/linux/nd.h| 46 +++ >> 6 files changed, 678 insertions(+) >> create mode 100644 drivers/nvdimm/nd_perf.c >> > Thanks and Regards, > R.Nageswara Sastry > >> >
Re: [PATCH 2/4] drivers/nvdimm: Add perf interface to expose nvdimm performance stats
On 6/8/21 11:06 PM, Peter Zijlstra wrote:
> On Tue, Jun 08, 2021 at 05:26:58PM +0530, Kajol Jain wrote:
>> +static int nvdimm_pmu_cpu_offline(unsigned int cpu, struct hlist_node *node)
>> +{
>> +struct nvdimm_pmu *nd_pmu;
>> +u32 target;
>> +int nodeid;
>> +const struct cpumask *cpumask;
>> +
>> +nd_pmu = hlist_entry_safe(node, struct nvdimm_pmu, node);
>> +
>> +/* Clear it, incase given cpu is set in nd_pmu->arch_cpumask */
>> +cpumask_test_and_clear_cpu(cpu, _pmu->arch_cpumask);
>> +
>> +/*
>> + * If given cpu is not same as current designated cpu for
>> + * counter access, just return.
>> + */
>> +if (cpu != nd_pmu->cpu)
>> +return 0;
>> +
>> +/* Check for any active cpu in nd_pmu->arch_cpumask */
>> +target = cpumask_any(_pmu->arch_cpumask);
>> +nd_pmu->cpu = target;
>> +
>> +/*
>> + * Incase we don't have any active cpu in nd_pmu->arch_cpumask,
>> + * check in given cpu's numa node list.
>> + */
>> +if (target >= nr_cpu_ids) {
>> +nodeid = cpu_to_node(cpu);
>> +cpumask = cpumask_of_node(nodeid);
>> +target = cpumask_any_but(cpumask, cpu);
>> +nd_pmu->cpu = target;
>> +
>> +if (target >= nr_cpu_ids)
>> +return -1;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static int nvdimm_pmu_cpu_online(unsigned int cpu, struct hlist_node *node)
>> +{
>> +struct nvdimm_pmu *nd_pmu;
>> +
>> +nd_pmu = hlist_entry_safe(node, struct nvdimm_pmu, node);
>> +
>> +if (nd_pmu->cpu >= nr_cpu_ids)
>> +nd_pmu->cpu = cpu;
>> +
>> +return 0;
>> +}
>
>> +static int nvdimm_pmu_cpu_hotplug_init(struct nvdimm_pmu *nd_pmu)
>> +{
>> +int nodeid, rc;
>> +const struct cpumask *cpumask;
>> +
>> +/*
>> + * Incase cpu hotplug is not handled by arch specific code
>> + * they can still provide required cpumask which can be used
>> + * to get designatd cpu for counter access.
>> + * Check for any active cpu in nd_pmu->arch_cpumask.
>> + */
>> +if (!cpumask_empty(_pmu->arch_cpumask)) {
>> +nd_pmu->cpu = cpumask_any(_pmu->arch_cpumask);
>> +} else {
>> +/* pick active cpu from the cpumask of device numa node. */
>> +nodeid = dev_to_node(nd_pmu->dev);
>> +cpumask = cpumask_of_node(nodeid);
>> +nd_pmu->cpu = cpumask_any(cpumask);
>> +}
>> +
>> +rc = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN, "perf/nvdimm:online",
>> + nvdimm_pmu_cpu_online,
>> nvdimm_pmu_cpu_offline);
>> +
>
> Did you actually test this hotplug stuff?
>
> That is, create a counter, unplug the CPU the counter was on, and
> continue counting? "perf stat -I" is a good option for this, concurrent
> with a hotplug.
>
> Because I don't think it's actually correct. The thing is perf core is
> strictly per-cpu, and it will place the event on a specific CPU context.
> If you then unplug that CPU, nothing will touch the events on that CPU
> anymore.
>
> What drivers that span CPUs need to do is call
> perf_pmu_migrate_context() whenever the CPU they were assigned to goes
> away. Please have a look at arch/x86/events/rapl.c or
> arch/x86/events/amd/power.c for relatively simple drivers that have this
> property.
>
Hi Peter,
Primarily I tested off-lining multiple cpus and checking if cpumask file is
updating as expected,
followed with perf stat commands.
But I missed the scenario where we are off-lining CPU while running perf stat.
My bad, thanks
for pointing it out.
I will fix this issue and send new version of the patchset.
Thanks,
Kajol Jain
>
Re: [PATCH] perf vendor events: Fix eventcode of power10 json events
On 5/26/21 11:42 AM, Nageswara Sastry wrote: > > >> On 25-May-2021, at 8:57 PM, Paul A. Clarke wrote: >>> >> I lost the original message, but Nageswara Sastry said: >>> 1. Extracted all the 244 events from the patch. >>> 2. Check them in 'perf list' - all 244 events found >>> 3. Ran all the events with 'perf stat -e "event name" sleep 1', all ran >>> fine. >>>No errors were seen in 'dmesg' >> >> I count 255 events. >> >> PC > > Seems while extracting I filtered out newly added ones, so I got 244(255-11). > Now checked with all 255 events. Thanks for pointing out. > > Thanks!! > R.Nageswara Sastry > Hi Paul/Nageswara, Yes we currently have 255 power10 json events which is updated in this patch. Thanks for reviewing the patch. Arnaldo can you pull this patch if changes looks fine to you. Thanks, Kajol Jain
Re: [RFC v2 4/4] powerpc/papr_scm: Add cpu hotplug support for nvdimm pmu device
On 5/26/21 2:02 PM, Peter Zijlstra wrote: > On Wed, May 26, 2021 at 12:56:58PM +0530, kajoljain wrote: >> On 5/25/21 7:46 PM, Peter Zijlstra wrote: >>> On Tue, May 25, 2021 at 06:52:16PM +0530, Kajol Jain wrote: > >>>> It adds cpumask to designate a cpu to make HCALL to >>>> collect the counter data for the nvdimm device and >>>> update ABI documentation accordingly. >>>> >>>> Result in power9 lpar system: >>>> command:# cat /sys/devices/nmem0/cpumask >>>> 0 >>> >>> Is this specific to the papr thing, or should this be in generic nvdimm >>> code? >> >> This code is not specific to papr device and we can move it to >> generic nvdimm interface. But do we need to add some checks on whether >> any arch/platform specific driver want that support or we can assume >> that this will be something needed by all platforms? > > I'm a complete NVDIMM n00b, but to me it would appear they would have to > conform to the normal memory hierarchy and would thus always be > per-node. > > Also, if/when deviation from this rule is observed, we can always > rework/extend this. For now I think it would make sense to have the > per-node ness of the thing expressed in the generic layer. > Hi Peter, Thanks for the suggestion, I will send new RFC patchset with these changes. Thanks, Kajol Jain
Re: [RFC v2 4/4] powerpc/papr_scm: Add cpu hotplug support for nvdimm pmu device
On 5/26/21 2:15 PM, Aneesh Kumar K.V wrote: > On 5/26/21 12:56 PM, kajoljain wrote: >> >> >> On 5/25/21 7:46 PM, Peter Zijlstra wrote: >>> On Tue, May 25, 2021 at 06:52:16PM +0530, Kajol Jain wrote: >>>> Patch here adds cpu hotplug functions to nvdimm pmu. >>> >>> I'm thinking "Patch here" qualifies for "This patch", see >>> Documentation/process/submitting-patches.rst . >>> >> Hi Peter, >> I will reword this commit message. >> >>>> It adds cpumask to designate a cpu to make HCALL to >>>> collect the counter data for the nvdimm device and >>>> update ABI documentation accordingly. >>>> >>>> Result in power9 lpar system: >>>> command:# cat /sys/devices/nmem0/cpumask >>>> 0 >>> >>> Is this specific to the papr thing, or should this be in generic nvdimm >>> code? >> >> This code is not specific to papr device and we can move it to >> generic nvdimm interface. But do we need to add some checks on whether >> any arch/platform specific driver want that support or we can assume >> that this will be something needed by all platforms? >> > > It says the cpu that should be used to make the hcall. That makes it PAPR > specific. Hi Aneesh, The hcall in the commit message basically pointing to the method we used to get counter data. But adding cpumask to a PMU is not specific to powerpc. So, Incase other platform/arch want to enable hotplug feature, they can use same code for that and hence we can move it to generic nvdimm interface. Our concerned it mainly about is it right to assume from the common code point of view, if the cpumask attr is null, common code can add the cpumask support to it, or do we need to have explicit flag for the device to request for it. Thanks, Kajol Jain > > -aneesh >
Re: [RFC v2 4/4] powerpc/papr_scm: Add cpu hotplug support for nvdimm pmu device
On 5/25/21 7:46 PM, Peter Zijlstra wrote: > On Tue, May 25, 2021 at 06:52:16PM +0530, Kajol Jain wrote: >> Patch here adds cpu hotplug functions to nvdimm pmu. > > I'm thinking "Patch here" qualifies for "This patch", see > Documentation/process/submitting-patches.rst . > Hi Peter, I will reword this commit message. >> It adds cpumask to designate a cpu to make HCALL to >> collect the counter data for the nvdimm device and >> update ABI documentation accordingly. >> >> Result in power9 lpar system: >> command:# cat /sys/devices/nmem0/cpumask >> 0 > > Is this specific to the papr thing, or should this be in generic nvdimm > code? This code is not specific to papr device and we can move it to generic nvdimm interface. But do we need to add some checks on whether any arch/platform specific driver want that support or we can assume that this will be something needed by all platforms? Thanks, Kajol Jain
Re: [PATCH v3] powerpc/papr_scm: Reduce error severity if nvdimm stats inaccessible
On 5/8/21 10:06 AM, Vaibhav Jain wrote:
> Currently drc_pmem_qeury_stats() generates a dev_err in case
> "Enable Performance Information Collection" feature is disabled from
> HMC or performance stats are not available for an nvdimm. The error is
> of the form below:
>
> papr_scm ibm,persistent-memory:ibm,pmemory@44104001: Failed to query
>performance stats, Err:-10
>
> This error message confuses users as it implies a possible problem
> with the nvdimm even though its due to a disabled/unavailable
> feature. We fix this by explicitly handling the H_AUTHORITY and
> H_UNSUPPORTED errors from the H_SCM_PERFORMANCE_STATS hcall.
>
> In case of H_AUTHORITY error an info message is logged instead of an
> error, saying that "Permission denied while accessing performance
> stats" and an EPERM error is returned back.
>
> In case of H_UNSUPPORTED error we return a EOPNOTSUPP error back from
> drc_pmem_query_stats() indicating that performance stats-query
> operation is not supported on this nvdimm.
>
> Fixes: 2d02bf835e57('powerpc/papr_scm: Fetch nvdimm performance stats from
> PHYP')
> Signed-off-by: Vaibhav Jain
> ---
> Changelog
>
> v3:
> * Return EOPNOTSUPP error in case of H_UNSUPPORTED [ Ira ]
> * Return EPERM in case of H_AUTHORITY [ Ira ]
> * Updated patch description
>
Patch looks good to me.
Reviewed-By: Kajol Jain
Thanks,
Kajol Jain
> v2:
> * Updated the message logged in case of H_AUTHORITY error [ Ira ]
> * Switched from dev_warn to dev_info in case of H_AUTHORITY error.
> * Instead of -EPERM return -EACCESS for H_AUTHORITY error.
> * Added explicit handling of H_UNSUPPORTED error.
> ---
> arch/powerpc/platforms/pseries/papr_scm.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c
> b/arch/powerpc/platforms/pseries/papr_scm.c
> index ef26fe40efb0..e2b69cc3beaf 100644
> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> @@ -310,6 +310,13 @@ static ssize_t drc_pmem_query_stats(struct papr_scm_priv
> *p,
> dev_err(>pdev->dev,
> "Unknown performance stats, Err:0x%016lX\n", ret[0]);
> return -ENOENT;
> + } else if (rc == H_AUTHORITY) {
> + dev_info(>pdev->dev,
> + "Permission denied while accessing performance stats");
> + return -EPERM;
> + } else if (rc == H_UNSUPPORTED) {
> + dev_dbg(>pdev->dev, "Performance stats unsupported\n");
> + return -EOPNOTSUPP;
> } else if (rc != H_SUCCESS) {
> dev_err(>pdev->dev,
> "Failed to query performance stats, Err:%lld\n", rc);
>
Re: [RFC 1/4] drivers/nvdimm: Add perf interface to expose nvdimm performance stats
On 5/14/21 5:17 PM, Peter Zijlstra wrote:
> On Thu, May 13, 2021 at 05:56:14PM +0530, kajoljain wrote:
>
>> But yes the current read/add/del functions are not adding value. We
>> could add an arch/platform specific function which could handle the
>> capturing of the counter data and do the rest of the operation here,
>> is this approach better?
>
> Right; have your register_nvdimm_pmu() set pmu->{add,del,read} to
> nd_pmu->{add,del,read} directly, don't bother with these intermediates.
> Also you can WARN_ON_ONCE() if any of them are NULL and fail
> registration at that point.
>
Hi Peter,
I will make all required changes and send next version of this patchset
soon.
Thanks,
Kajol Jain
Re: [RFC 1/4] drivers/nvdimm: Add perf interface to expose nvdimm performance stats
On 5/12/21 10:57 PM, Peter Zijlstra wrote:
> On Wed, May 12, 2021 at 10:08:21PM +0530, Kajol Jain wrote:
>> +static void nvdimm_pmu_read(struct perf_event *event)
>> +{
>> +struct nvdimm_pmu *nd_pmu = to_nvdimm_pmu(event->pmu);
>> +
>> +/* jump to arch/platform specific callbacks if any */
>> +if (nd_pmu && nd_pmu->read)
>> +nd_pmu->read(event, nd_pmu->dev);
>> +}
>> +
>> +static void nvdimm_pmu_del(struct perf_event *event, int flags)
>> +{
>> +struct nvdimm_pmu *nd_pmu = to_nvdimm_pmu(event->pmu);
>> +
>> +/* jump to arch/platform specific callbacks if any */
>> +if (nd_pmu && nd_pmu->del)
>> +nd_pmu->del(event, flags, nd_pmu->dev);
>> +}
>> +
>> +static int nvdimm_pmu_add(struct perf_event *event, int flags)
>> +{
>> +struct nvdimm_pmu *nd_pmu = to_nvdimm_pmu(event->pmu);
>> +
>> +if (flags & PERF_EF_START)
>> +/* jump to arch/platform specific callbacks if any */
>> +if (nd_pmu && nd_pmu->add)
>> +return nd_pmu->add(event, flags, nd_pmu->dev);
>> +return 0;
>> +}
>
> What's the value add here? Why can't you directly set driver pointers? I
> also don't really believe ->{add,del,read} can be optional and still
> have a sane driver.
>
Hi Peter,
The intend for adding these callbacks is to give flexibility to the
arch/platform specific driver code to use its own routine for getting
counter data or specific checks/operations. Arch/platform driver code
would have different method to get the counter data like IBM pseries
nmem* device which uses a hypervisor call(hcall).
But yes the current read/add/del functions are not adding value. We
could add an arch/platform specific function which could handle the
capturing of the counter data and do the rest of the operation here,
is this approach better?
Thanks,
Kajol Jain
Re: [PATCH] perf vendor events: Initial json/events list for power10 platform
On 4/19/21 2:38 AM, Paul A. Clarke wrote: > On Sat, Apr 17, 2021 at 02:48:50PM +0530, Kajol Jain wrote: >> Patch adds initial json/events for POWER10. > > I was able to apply, build, and run perf with these changes, > and every new event at least ran successfully with > `perf stat`. > > Pedantically, there is a lot of inconsistency as to whether > the `BriefDescription` ends with a period or not, and whether > there is an extra space at the end. Hi Paul, Thanks for reviewing the patch. Sure I will remove this inconsistency and send v2 patch for the same, with your Tested-by and Reviewed-by tag. Thanks, Kajol Jain > > Regardless, LGTM. > > Tested-by: Paul A. Clarke > Reviewed-by: Paul A. Clarke > > PC >
Re: [PATCH] powerpc/papr_scm: Reduce error severity if nvdimm stats inaccessible
On 4/15/21 5:18 PM, Vaibhav Jain wrote:
> Ira Weiny writes:
>
>> On Wed, Apr 14, 2021 at 09:51:40PM +0530, Vaibhav Jain wrote:
>>> Thanks for looking into this patch Ira,
>>>
>>> Ira Weiny writes:
>>>
On Wed, Apr 14, 2021 at 06:10:26PM +0530, Vaibhav Jain wrote:
> Currently drc_pmem_qeury_stats() generates a dev_err in case
> "Enable Performance Information Collection" feature is disabled from
> HMC. The error is of the form below:
>
> papr_scm ibm,persistent-memory:ibm,pmemory@44104001: Failed to query
>performance stats, Err:-10
>
> This error message confuses users as it implies a possible problem
> with the nvdimm even though its due to a disabled feature.
>
> So we fix this by explicitly handling the H_AUTHORITY error from the
> H_SCM_PERFORMANCE_STATS hcall and generating a warning instead of an
> error, saying that "Performance stats in-accessible".
>
> Fixes: 2d02bf835e57('powerpc/papr_scm: Fetch nvdimm performance stats
> from PHYP')
> Signed-off-by: Vaibhav Jain
> ---
> arch/powerpc/platforms/pseries/papr_scm.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c
> b/arch/powerpc/platforms/pseries/papr_scm.c
> index 835163f54244..9216424f8be3 100644
> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> @@ -277,6 +277,9 @@ static ssize_t drc_pmem_query_stats(struct
> papr_scm_priv *p,
> dev_err(>pdev->dev,
> "Unknown performance stats, Err:0x%016lX\n", ret[0]);
> return -ENOENT;
> + } else if (rc == H_AUTHORITY) {
> + dev_warn(>pdev->dev, "Performance stats in-accessible");
> + return -EPERM;
Is this because of a disabled feature or because of permissions?
>>>
>>> Its because of a disabled feature that revokes permission for a guest to
>>> retrieve performance statistics.
>>>
>>> The feature is called "Enable Performance Information Collection" and
>>> once disabled the hcall H_SCM_PERFORMANCE_STATS returns an error
>>> H_AUTHORITY indicating that the guest doesn't have permission to retrieve
>>> performance statistics.
>>
>> In that case would it be appropriate to have the error message indicate a
>> permission issue?
>>
>> Something like 'permission denied'?
>
> Yes, Something like "Permission denied while accessing performance
> stats" might be more clear and intuitive.
Hi Vaibhav,
Thanks for the patch. I agree with Ira and above warning message with
"Permission denied" looks more clear.
With that change, patch looks good to me.
Reviewed-By: Kajol Jain
Thanks,
Kajol Jain
>
> Will update the warn message in v2.
>
>>
>> Ira
>>
>
Re: [PATCH -next] powerpc/perf: Make symbol 'isa207_pmu_format_attr' static
On 4/9/21 2:31 PM, Bixuan Cui wrote:
> The sparse tool complains as follows:
>
> arch/powerpc/perf/isa207-common.c:24:18: warning:
> symbol 'isa207_pmu_format_attr' was not declared. Should it be static?
>
> This symbol is not used outside of isa207-common.c, so this
> commit marks it static.
Patch looks good to me.
Reviewed-by: Kajol Jain
Thanks,
Kajol Jain
>
> Reported-by: Hulk Robot
> Signed-off-by: Bixuan Cui
> ---
> arch/powerpc/perf/isa207-common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/perf/isa207-common.c
> b/arch/powerpc/perf/isa207-common.c
> index e4f577da33d8..487f9e914b5c 100644
> --- a/arch/powerpc/perf/isa207-common.c
> +++ b/arch/powerpc/perf/isa207-common.c
> @@ -21,7 +21,7 @@ PMU_FORMAT_ATTR(thresh_stop,"config:32-35");
> PMU_FORMAT_ATTR(thresh_start,"config:36-39");
> PMU_FORMAT_ATTR(thresh_cmp, "config:40-49");
>
> -struct attribute *isa207_pmu_format_attr[] = {
> +static struct attribute *isa207_pmu_format_attr[] = {
> _attr_event.attr,
> _attr_pmcxsel.attr,
> _attr_mark.attr,
>
Re: [PATCH -next] powerpc/perf/hv-24x7: Make some symbols static
On 4/9/21 2:31 PM, Bixuan Cui wrote:
> The sparse tool complains as follows:
>
> arch/powerpc/perf/hv-24x7.c:229:1: warning:
> symbol '__pcpu_scope_hv_24x7_txn_flags' was not declared. Should it be
> static?
> arch/powerpc/perf/hv-24x7.c:230:1: warning:
> symbol '__pcpu_scope_hv_24x7_txn_err' was not declared. Should it be static?
> arch/powerpc/perf/hv-24x7.c:236:1: warning:
> symbol '__pcpu_scope_hv_24x7_hw' was not declared. Should it be static?
> arch/powerpc/perf/hv-24x7.c:244:1: warning:
> symbol '__pcpu_scope_hv_24x7_reqb' was not declared. Should it be static?
> arch/powerpc/perf/hv-24x7.c:245:1: warning:
> symbol '__pcpu_scope_hv_24x7_resb' was not declared. Should it be static?
>
> This symbol is not used outside of hv-24x7.c, so this
> commit marks it static.
Patch looks good to me.
Reviewed-By: Kajol Jain
Thanks,
Kajol jain
>
> Reported-by: Hulk Robot
> Signed-off-by: Bixuan Cui
> ---
> arch/powerpc/perf/hv-24x7.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
> index e5eb33255066..1816f560a465 100644
> --- a/arch/powerpc/perf/hv-24x7.c
> +++ b/arch/powerpc/perf/hv-24x7.c
> @@ -226,14 +226,14 @@ static struct attribute_group event_long_desc_group = {
>
> static struct kmem_cache *hv_page_cache;
>
> -DEFINE_PER_CPU(int, hv_24x7_txn_flags);
> -DEFINE_PER_CPU(int, hv_24x7_txn_err);
> +static DEFINE_PER_CPU(int, hv_24x7_txn_flags);
> +static DEFINE_PER_CPU(int, hv_24x7_txn_err);
>
> struct hv_24x7_hw {
> struct perf_event *events[255];
> };
>
> -DEFINE_PER_CPU(struct hv_24x7_hw, hv_24x7_hw);
> +static DEFINE_PER_CPU(struct hv_24x7_hw, hv_24x7_hw);
>
> /*
> * request_buffer and result_buffer are not required to be 4k aligned,
> @@ -241,8 +241,8 @@ DEFINE_PER_CPU(struct hv_24x7_hw, hv_24x7_hw);
> * the simplest way to ensure that.
> */
> #define H24x7_DATA_BUFFER_SIZE 4096
> -DEFINE_PER_CPU(char, hv_24x7_reqb[H24x7_DATA_BUFFER_SIZE]) __aligned(4096);
> -DEFINE_PER_CPU(char, hv_24x7_resb[H24x7_DATA_BUFFER_SIZE]) __aligned(4096);
> +static DEFINE_PER_CPU(char, hv_24x7_reqb[H24x7_DATA_BUFFER_SIZE])
> __aligned(4096);
> +static DEFINE_PER_CPU(char, hv_24x7_resb[H24x7_DATA_BUFFER_SIZE])
> __aligned(4096);
>
> static unsigned int max_num_requests(int interface_version)
> {
>
Re: [PATCH v3 1/2] powerpc/perf: Use PVR rather than oprofile field to determine CPU version
On 3/1/21 5:39 PM, Christophe Leroy wrote:
> From: Rashmica Gupta
>
> Currently the perf CPU backend drivers detect what CPU they're on using
> cur_cpu_spec->oprofile_cpu_type.
>
> Although that works, it's a bit crufty to be using oprofile related fields,
> especially seeing as oprofile is more or less unused these days.
>
> It also means perf is reliant on the fragile logic in setup_cpu_spec()
> which detects when we're using a logical PVR and copies back the PMU
> related fields from the raw CPU entry. So lets check the PVR directly.
>
> Suggested-by: Michael Ellerman
> Signed-off-by: Rashmica Gupta
> Reviewed-by: Madhavan Srinivasan
> [chleroy: Added power10 and fixed checkpatch issues]
> Signed-off-by: Christophe Leroy
Patch looks good to me.
Reviewed-and-tested-By: Kajol Jain [For 24x7 side changes]
Thanks,
Kajol Jain
> ---
> arch/powerpc/perf/e500-pmu.c| 9 +
> arch/powerpc/perf/e6500-pmu.c | 5 +++--
> arch/powerpc/perf/hv-24x7.c | 6 +++---
> arch/powerpc/perf/mpc7450-pmu.c | 5 +++--
> arch/powerpc/perf/power10-pmu.c | 6 ++
> arch/powerpc/perf/power5+-pmu.c | 6 +++---
> arch/powerpc/perf/power5-pmu.c | 5 +++--
> arch/powerpc/perf/power6-pmu.c | 5 +++--
> arch/powerpc/perf/power7-pmu.c | 7 ---
> arch/powerpc/perf/power8-pmu.c | 5 +++--
> arch/powerpc/perf/power9-pmu.c | 4 +---
> arch/powerpc/perf/ppc970-pmu.c | 7 ---
> 12 files changed, 37 insertions(+), 33 deletions(-)
>
> diff --git a/arch/powerpc/perf/e500-pmu.c b/arch/powerpc/perf/e500-pmu.c
> index a59c33bed32a..e3e1a68eb1d5 100644
> --- a/arch/powerpc/perf/e500-pmu.c
> +++ b/arch/powerpc/perf/e500-pmu.c
> @@ -118,12 +118,13 @@ static struct fsl_emb_pmu e500_pmu = {
>
> static int init_e500_pmu(void)
> {
> - if (!cur_cpu_spec->oprofile_cpu_type)
> - return -ENODEV;
> + unsigned int pvr = mfspr(SPRN_PVR);
>
> - if (!strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/e500mc"))
> + /* ec500mc */
> + if (PVR_VER(pvr) == PVR_VER_E500MC || PVR_VER(pvr) == PVR_VER_E5500)
> num_events = 256;
> - else if (strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/e500"))
> + /* e500 */
> + else if (PVR_VER(pvr) != PVR_VER_E500V1 && PVR_VER(pvr) !=
> PVR_VER_E500V2)
> return -ENODEV;
>
> return register_fsl_emb_pmu(_pmu);
> diff --git a/arch/powerpc/perf/e6500-pmu.c b/arch/powerpc/perf/e6500-pmu.c
> index 44ad65da82ed..bd779a2338f8 100644
> --- a/arch/powerpc/perf/e6500-pmu.c
> +++ b/arch/powerpc/perf/e6500-pmu.c
> @@ -107,8 +107,9 @@ static struct fsl_emb_pmu e6500_pmu = {
>
> static int init_e6500_pmu(void)
> {
> - if (!cur_cpu_spec->oprofile_cpu_type ||
> - strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/e6500"))
> + unsigned int pvr = mfspr(SPRN_PVR);
> +
> + if (PVR_VER(pvr) != PVR_VER_E6500)
> return -ENODEV;
>
> return register_fsl_emb_pmu(_pmu);
> diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
> index e5eb33255066..f3f2472fa1c6 100644
> --- a/arch/powerpc/perf/hv-24x7.c
> +++ b/arch/powerpc/perf/hv-24x7.c
> @@ -1718,16 +1718,16 @@ static int hv_24x7_init(void)
> {
> int r;
> unsigned long hret;
> + unsigned int pvr = mfspr(SPRN_PVR);
> struct hv_perf_caps caps;
>
> if (!firmware_has_feature(FW_FEATURE_LPAR)) {
> pr_debug("not a virtualized system, not enabling\n");
> return -ENODEV;
> - } else if (!cur_cpu_spec->oprofile_cpu_type)
> - return -ENODEV;
> + }
>
> /* POWER8 only supports v1, while POWER9 only supports v2. */
> - if (!strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power8"))
> + if (PVR_VER(pvr) == PVR_POWER8)
> interface_version = 1;
> else {
> interface_version = 2;
> diff --git a/arch/powerpc/perf/mpc7450-pmu.c b/arch/powerpc/perf/mpc7450-pmu.c
> index e39b15b79a83..552d51a925d3 100644
> --- a/arch/powerpc/perf/mpc7450-pmu.c
> +++ b/arch/powerpc/perf/mpc7450-pmu.c
> @@ -417,8 +417,9 @@ struct power_pmu mpc7450_pmu = {
>
> static int __init init_mpc7450_pmu(void)
> {
> - if (!cur_cpu_spec->oprofile_cpu_type ||
> - strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/7450"))
> + unsigned int pvr = mfspr(SPRN_PVR);
> +
> + if (PVR_VER(pvr) != PVR_7450)
> return -ENODEV;
>
> return register_power_pmu(_pmu);
> diff --git a/arch/powerpc/perf/power10-pmu.c b/arch/powerpc/perf/power10-pmu.c
> index a901c1348cad..d1395844a329 100644
> --- a/arch/powerpc/perf/power10-pmu.c
> +++ b/arch/powerpc/perf/power10-pmu.c
> @@ -566,12 +566,10 @@ int init_power10_pmu(void)
> unsigned int pvr;
> int rc;
>
> - /* Comes from cpu_specs[] */
> - if (!cur_cpu_spec->oprofile_cpu_type ||
> - strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power10"))
> + pvr = mfspr(SPRN_PVR);
> + if (PVR_VER(pvr) != PVR_POWER10)
> return -ENODEV;
>
> - pvr =
Re: [PATCH] tools/perf: Fix powerpc gap between kernel end and module start
On 1/12/21 3:08 PM, Jiri Olsa wrote:
> On Mon, Dec 28, 2020 at 09:14:14PM -0500, Athira Rajeev wrote:
>
> SNIP
>
>> c2799370 b backtrace_flag
>> c2799378 B radix_tree_node_cachep
>> c2799380 B __bss_stop
>> c27a B _end
>> c0080389 t icmp_checkentry [ip_tables]
>> c00803890038 t ipt_alloc_initial_table [ip_tables]
>> c00803890468 T ipt_do_table [ip_tables]
>> c00803890de8 T ipt_unregister_table_pre_exit[ip_tables]
>> ...
>>
>> Perf calls function symbols__fixup_end() which sets the end of symbol
>> to 0xc0080389, which is the next address and this is the start
>> address of first module (icmp_checkentry in above) which will make the
>> huge symbol size of 0x8010f.
>>
>> After symbols__fixup_end:
>> symbols__fixup_end: sym->name: _end, sym->start: 0xc27a,
>> sym->end: 0xc0080389
>>
>> On powerpc, kernel text segment is located at 0xc000
>> whereas the modules are located at very high memory addresses,
>> 0xc0080xxx. Since the gap between end of kernel text segment
>> and beginning of first module's address is high, histogram allocation
>> using calloc fails.
>>
>> Fix this by detecting the kernel's last symbol and limiting
>> the range of last kernel symbol to pagesize.
Patch looks good to me.
Tested-By: Kajol Jain
Thanks,
Kajol Jain
>>
>> Signed-off-by: Athira Rajeev
>
> I can't test, but since the same approach works for arm and s390,
> this also looks ok
>
> Acked-by: Jiri Olsa
>
> thanks,
> jirka
>
>> ---
>> tools/perf/arch/powerpc/util/Build | 1 +
>> tools/perf/arch/powerpc/util/machine.c | 24
>> 2 files changed, 25 insertions(+)
>> create mode 100644 tools/perf/arch/powerpc/util/machine.c
>>
>> diff --git a/tools/perf/arch/powerpc/util/Build
>> b/tools/perf/arch/powerpc/util/Build
>> index e86e210bf514..b7945e5a543b 100644
>> --- a/tools/perf/arch/powerpc/util/Build
>> +++ b/tools/perf/arch/powerpc/util/Build
>> @@ -1,4 +1,5 @@
>> perf-y += header.o
>> +perf-y += machine.o
>> perf-y += kvm-stat.o
>> perf-y += perf_regs.o
>> perf-y += mem-events.o
>> diff --git a/tools/perf/arch/powerpc/util/machine.c
>> b/tools/perf/arch/powerpc/util/machine.c
>> new file mode 100644
>> index ..c30e5cc88c16
>> --- /dev/null
>> +++ b/tools/perf/arch/powerpc/util/machine.c
>> @@ -0,0 +1,24 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +#include
>> +#include
>> +#include // page_size
>> +#include "debug.h"
>> +#include "symbol.h"
>> +
>> +/* On powerpc kernel text segment start at memory addresses,
>> 0xc000
>> + * whereas the modules are located at very high memory addresses,
>> + * for example 0xc0080xxx. The gap between end of kernel text
>> segment
>> + * and beginning of first module's text segment is very high.
>> + * Therefore do not fill this gap and do not assign it to the kernel dso
>> map.
>> + */
>> +
>> +void arch__symbols__fixup_end(struct symbol *p, struct symbol *c)
>> +{
>> +if (strchr(p->name, '[') == NULL && strchr(c->name, '['))
>> +/* Limit the range of last kernel symbol */
>> +p->end += page_size;
>> +else
>> +p->end = c->start;
>> +pr_debug4("%s sym:%s end:%#lx\n", __func__, p->name, p->end);
>> +}
>> --
>> 1.8.3.1
>>
>
Re: [PATCH v2] powerpc/perf/hv-24x7: Dont create sysfs event files for dummy events
On 12/21/20 11:10 AM, Michael Ellerman wrote:
> Kajol Jain writes:
>> hv_24x7 performance monitoring unit creates list of supported events
>> from the event catalog obtained via HCALL. hv_24x7 catalog could also
>> contain invalid or dummy events (with names like FREE_* or CPM_FREE_*
>> and RESERVED*). These events do not have any hardware counters
>> backing them. So patch adds a check to string compare the event names
>> to filter out them.
>>
>> Result in power9 machine:
>>
>> Before this patch:
>> .
>> hv_24x7/PM_XLINK2_OUT_ODD_CYC,chip=?/ [Kernel PMU event]
>> hv_24x7/PM_XLINK2_OUT_ODD_DATA_COUNT,chip=?/ [Kernel PMU event]
>> hv_24x7/PM_XLINK2_OUT_ODD_TOTAL_UTIL,chip=?/ [Kernel PMU event]
>> hv_24x7/PM_XTS_ATR_DEMAND_CHECKOUT,chip=?/ [Kernel PMU event]
>> hv_24x7/PM_XTS_ATR_DEMAND_CHECKOUT_MISS,chip=?/[Kernel PMU event]
>> hv_24x7/PM_XTS_ATSD_SENT,chip=?/ [Kernel PMU event]
>> hv_24x7/PM_XTS_ATSD_TLBI_RCV,chip=?/ [Kernel PMU event]
>> hv_24x7/RESERVED_NEST1,chip=?/ [Kernel PMU event]
>> hv_24x7/RESERVED_NEST10,chip=?/[Kernel PMU event]
>> hv_24x7/RESERVED_NEST11,chip=?/[Kernel PMU event]
>> hv_24x7/RESERVED_NEST12,chip=?/[Kernel PMU event]
>> hv_24x7/RESERVED_NEST13,chip=?/[Kernel PMU event]
>> ..
>>
>> Dmesg:
>> [0.000362] printk: console [hvc0] enabled
>> [0.815452] hv-24x7: read 1530 catalog entries, created 537 event attrs
>> (0 failures), 275 descs
>>
>> After this patch:
>> ..
>> hv_24x7/PM_XLINK2_OUT_ODD_AVLBL_CYC,chip=?/[Kernel PMU event]
>> hv_24x7/PM_XLINK2_OUT_ODD_CYC,chip=?/ [Kernel PMU event]
>> hv_24x7/PM_XLINK2_OUT_ODD_DATA_COUNT,chip=?/ [Kernel PMU event]
>> hv_24x7/PM_XLINK2_OUT_ODD_TOTAL_UTIL,chip=?/ [Kernel PMU event]
>> hv_24x7/PM_XTS_ATR_DEMAND_CHECKOUT,chip=?/ [Kernel PMU event]
>> hv_24x7/PM_XTS_ATR_DEMAND_CHECKOUT_MISS,chip=?/[Kernel PMU event]
>> hv_24x7/PM_XTS_ATSD_SENT,chip=?/ [Kernel PMU event]
>> hv_24x7/PM_XTS_ATSD_TLBI_RCV,chip=?/ [Kernel PMU event]
>> hv_24x7/TOD,chip=?/[Kernel PMU event]
>> ..
>>
>> Demsg:
>> [0.000357] printk: console [hvc0] enabled
>> [0.808592] hv-24x7: read 1530 catalog entries, created 509 event attrs
>> (0 failures), 275 descs
>>
>> Signed-off-by: Kajol Jain
>> ---
>> arch/powerpc/perf/hv-24x7.c | 17 +
>> 1 file changed, 17 insertions(+)
>>
>> ---
>> Changelog
>> v1 -> v2
>> - Include "RESERVED*" as part of the invalid event check as
>> suggested by Madhavan Srinivasan
>> - Add new helper function "ignore_event" to check invalid/dummy
>> events as suggested by Michael Ellerman
>> - Remove pr_info to print each invalid event as suggested by
>> Michael Ellerman
>> ---
>> diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
>> index 6e7e820508df..1a6004d88f98 100644
>> --- a/arch/powerpc/perf/hv-24x7.c
>> +++ b/arch/powerpc/perf/hv-24x7.c
>> @@ -764,6 +764,16 @@ static ssize_t catalog_event_len_validate(struct
>> hv_24x7_event_data *event,
>> return ev_len;
>> }
>>
>> +/*
>> + * Return true incase of invalid or dummy events with names like FREE_* or
>> CPM_FREE_*
>> + * and RESERVED*
>> + */
>> +static bool ignore_event(const char *name)
>> +{
>> +return (strstr(name, "FREE_") || !strncmp(name, "RESERVED", 8)) ?
>> +true : false;
>
> That's FREE_ anywhere in the string, which seems a bit loose.
>
> Do we have any documentation or anything that tells us that any event
> with "FREE_" in the name will always be invalid?
Hi Michael,
We don't have any such document which says any event with "FREE_"
in the name will be invalid. So I will replace strstr check with strcmp
to look for events with names have "FREE" or "CPM_FREE" at start.
Thanks,
Kajol Jain
>
> cheers
>
