Re: [PATCH 1/2] drivers/nvdimm: Fix build failure when CONFIG_PERF_EVENTS is not set

2022-03-23 Thread kajoljain



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

2022-03-23 Thread kajoljain



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

2022-03-22 Thread kajoljain



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

2022-03-22 Thread kajoljain



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: [PATCH v7 0/4] Add perf interface to expose nvdimm

2022-03-07 Thread kajoljain
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

2022-02-25 Thread kajoljain



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

2022-02-25 Thread kajoljain



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

2022-02-24 Thread kajoljain



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: [RESEND PATCH v5 0/4] Add perf interface to expose nvdimm

2021-11-16 Thread kajoljain



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 v5 0/4] Add perf interface to expose nvdimm

2021-10-13 Thread kajoljain
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: [RESEND PATCH v4 4/4] powerpc/papr_scm: Document papr_scm sysfs event format entries

2021-09-09 Thread kajoljain



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

2021-09-09 Thread kajoljain



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: [RFC PATCH] drivers/nvdimm: nvdimm_pmu_free_hotplug_memory() can be static

2021-09-04 Thread kajoljain



On 9/3/21 8:49 PM, kernel test robot wrote:
> drivers/nvdimm/nd_perf.c:159:6: warning: symbol 
> 'nvdimm_pmu_free_hotplug_memory' was not declared. Should it be static?
> 
> Reported-by: kernel test robot 
> Signed-off-by: kernel test robot 
> ---
>  nd_perf.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/nvdimm/nd_perf.c b/drivers/nvdimm/nd_perf.c
> index 4c49d1bc2a3c6..b129e5e702d59 100644
> --- a/drivers/nvdimm/nd_perf.c
> +++ b/drivers/nvdimm/nd_perf.c
> @@ -156,7 +156,7 @@ static int nvdimm_pmu_cpu_hotplug_init(struct nvdimm_pmu 
> *nd_pmu)
>   return 0;
>  }
>  
> -void nvdimm_pmu_free_hotplug_memory(struct nvdimm_pmu *nd_pmu)
> +static void nvdimm_pmu_free_hotplug_memory(struct nvdimm_pmu *nd_pmu)
>  {
>   cpuhp_state_remove_instance_nocalls(nd_pmu->cpuhp_state, _pmu->node);
>   cpuhp_remove_multi_state(nd_pmu->cpuhp_state);
> 

Hi,
   Thanks for reporting this issue, I will merge it in my followup patchset.

Thanks,
Kajol Jain



Re: [RESEND PATCH v4 2/4] drivers/nvdimm: Add perf interface to expose nvdimm performance stats

2021-09-04 Thread kajoljain



On 9/3/21 8:49 PM, kernel test robot wrote:
> Hi Kajol,
> 
> Thank you for the patch! Perhaps something to improve:
> 
> [auto build test WARNING on linux-nvdimm/libnvdimm-for-next]
> [also build test WARNING on powerpc/next linus/master v5.14 next-20210903]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
> 
> url:
> https://github.com/0day-ci/linux/commits/Kajol-Jain/Add-perf-interface-to-expose-nvdimm/20210903-131212
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git 
> libnvdimm-for-next
> config: x86_64-randconfig-s021-20210903 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
> reproduce:
> # apt-get install sparse
> # sparse version: v0.6.4-rc1-dirty
> # 
> https://github.com/0day-ci/linux/commit/f841601cc058e6033761bd2157b886a30190fc3a
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review 
> Kajol-Jain/Add-perf-interface-to-expose-nvdimm/20210903-131212
> git checkout f841601cc058e6033761bd2157b886a30190fc3a
> # save the attached .config to linux build tree
> make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir 
> ARCH=x86_64 SHELL=/bin/bash drivers/nvdimm/
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
> 
> 
> sparse warnings: (new ones prefixed by >>)
>>> drivers/nvdimm/nd_perf.c:159:6: sparse: sparse: symbol 
>>> 'nvdimm_pmu_free_hotplug_memory' was not declared. Should it be static?
> 
> Please review and possibly fold the followup patch.

Hi,
  Sure I will correct it and send follow-up patchset.

Thanks,
Kajol Jain

> 
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
> 



Re: [PATCH] perf vendor events: Initial json/events list for power10 platform

2021-04-19 Thread kajoljain



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 -next] powerpc/perf: Make symbol 'isa207_pmu_format_attr' static

2021-04-12 Thread kajoljain



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

2021-04-12 Thread kajoljain



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 v2 0/6] perf arm64 metricgroup support

2021-04-07 Thread kajoljain



On 3/25/21 4:03 PM, John Garry wrote:
> This series contains support to get basic metricgroups working for
> arm64 CPUs.
> 
> Initial support is added for HiSilicon hip08 platform.
> 
> Some sample usage on Huawei D06 board:
> 
>  $ ./perf list metric
> 
> List of pre-defined events (to be used in -e): 
> 
> Metrics: 
> 
>   bp_misp_flush
>[BP misp flush L3 topdown metric]
>   branch_mispredicts
>[Branch mispredicts L2 topdown metric]
>   core_bound
>[Core bound L2 topdown metric]
>   divider
>[Divider L3 topdown metric]
>   exe_ports_util
>[EXE ports util L3 topdown metric]
>   fetch_bandwidth_bound
>[Fetch bandwidth bound L2 topdown metric]
>   fetch_latency_bound
>[Fetch latency bound L2 topdown metric]
>   fsu_stall
>[FSU stall L3 topdown metric]
>   idle_by_icache_miss
> 
> $ sudo ./perf stat -v -M core_bound sleep 1
> Using CPUID 0x480fd010
> metric expr (exe_stall_cycle - (mem_stall_anyload + 
> armv8_pmuv3_0@event\=0x7005@)) / cpu_cycles for core_bound
> found event cpu_cycles
> found event armv8_pmuv3_0/event=0x7005/
> found event exe_stall_cycle
> found event mem_stall_anyload
> adding {cpu_cycles -> armv8_pmuv3_0/event=0x7001/
> mem_stall_anyload -> armv8_pmuv3_0/event=0x7004/
> Control descriptor is not initialized
> cpu_cycles: 989433 385050 385050
> armv8_pmuv3_0/event=0x7005/: 19207 385050 385050
> exe_stall_cycle: 900825 385050 385050
> mem_stall_anyload: 253516 385050 385050
> 
> Performance counter stats for 'sleep':
> 
> 989,433  cpu_cycles  # 0.63 core_bound
>   19,207  armv8_pmuv3_0/event=0x7005/
>  900,825  exe_stall_cycle
>  253,516  mem_stall_anyload
> 
>0.000805809 seconds time elapsed
> 
>0.000875000 seconds user
>0.0 seconds sys
>
> perf stat --topdown is not supported, as this requires the CPU PMU to
> expose (alias) events for the TopDown L1 metrics from sysfs, which arm 
> does not do. To get that to work, we probably need to make perf use the
> pmu-events cpumap to learn about those alias events.
> 
> Metric reuse support is added for pmu-events parse metric testcase.
> This had been broken on power9 recentlty:
> https://lore.kernel.org/lkml/20210324015418.gc8...@li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com/
>  

Patch set looks good to me.

Reviewed-By: Kajol Jain

Thanks,
Kajol jain

> 
> Differences to v1:
> - Add pmu_events_map__find() as arm64-specific function
> - Fix metric reuse for pmu-events parse metric testcase 
> 
> John Garry (6):
>   perf metricgroup: Make find_metric() public with name change
>   perf test: Handle metric reuse in pmu-events parsing test
>   perf pmu: Add pmu_events_map__find()
>   perf vendor events arm64: Add Hisi hip08 L1 metrics
>   perf vendor events arm64: Add Hisi hip08 L2 metrics
>   perf vendor events arm64: Add Hisi hip08 L3 metrics
> 
>  tools/perf/arch/arm64/util/Build  |   1 +
>  tools/perf/arch/arm64/util/pmu.c  |  25 ++
>  .../arch/arm64/hisilicon/hip08/metrics.json   | 233 ++
>  tools/perf/tests/pmu-events.c |  82 +-
>  tools/perf/util/metricgroup.c |  12 +-
>  tools/perf/util/metricgroup.h |   3 +-
>  tools/perf/util/pmu.c |   5 +
>  tools/perf/util/pmu.h |   1 +
>  tools/perf/util/s390-sample-raw.c |   4 +-
>  9 files changed, 355 insertions(+), 11 deletions(-)
>  create mode 100644 tools/perf/arch/arm64/util/pmu.c
>  create mode 100644 
> tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json
> 


Re: [PATCH v2 1/6] perf metricgroup: Make find_metric() public with name change

2021-04-06 Thread kajoljain



On 4/6/21 3:24 PM, John Garry wrote:
> On 02/04/2021 00:16, Ian Rogers wrote:
>> On Thu, Mar 25, 2021 at 3:38 AM John Garry  wrote:
>>>
>>> Function find_metric() is required for the metric processing in the
>>> pmu-events testcase, so make it public. Also change the name to include
>>> "metricgroup".
>>
>> Would it make more sense as "pmu_events_map__find_metric" ?
>>
> 
> So all functions apart from one in metricgroup.h are named metricgroup__XXX, 
> so I was trying to keep this style - apart from the double-underscore (which 
> can be remedied).
> 
> Personally I don't think pmu_events_map__find_metric name fits with that 
> convention.

I agree, most of the functions in metricgroup.c named as metricgroup__xxx. May 
be something like metricgroup__find_metric will be better.

Thanks,
Kajol Jain

> 
> Thanks,
> John
> 
>> Thanks,
>> Ian
>>
>>> Signed-off-by: John Garry 
>>> ---
>>>   tools/perf/util/metricgroup.c | 5 +++--
>>>   tools/perf/util/metricgroup.h | 3 ++-
>>>   2 files changed, 5 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
>>> index 6acb44ad439b..71a13406e0bd 100644
>>> --- a/tools/perf/util/metricgroup.c
>>> +++ b/tools/perf/util/metricgroup.c
>>> @@ -900,7 +900,8 @@ static int __add_metric(struct list_head *metric_list,
>>>  (match_metric(__pe->metric_group, __metric) ||  \
>>>   match_metric(__pe->metric_name, __metric)))
>>>
>>> -static struct pmu_event *find_metric(const char *metric, struct 
>>> pmu_events_map *map)
>>> +struct pmu_event *metrcgroup_find_metric(const char *metric,
>>> +    struct pmu_events_map *map)
>>>   {
>>>  struct pmu_event *pe;
>>>  int i;
>>> @@ -985,7 +986,7 @@ static int __resolve_metric(struct metric *m,
>>>  struct expr_id *parent;
>>>  struct pmu_event *pe;
>>>
>>> -   pe = find_metric(cur->key, map);
>>> +   pe = metrcgroup_find_metric(cur->key, map);
>>>  if (!pe)
>>>  continue;
>>>
>>> diff --git a/tools/perf/util/metricgroup.h b/tools/perf/util/metricgroup.h
>>> index ed1b9392e624..1674c6a36d74 100644
>>> --- a/tools/perf/util/metricgroup.h
>>> +++ b/tools/perf/util/metricgroup.h
>>> @@ -44,7 +44,8 @@ int metricgroup__parse_groups(const struct option *opt,
>>>    bool metric_no_group,
>>>    bool metric_no_merge,
>>>    struct rblist *metric_events);
>>> -
>>> +struct pmu_event *metrcgroup_find_metric(const char *metric,
>>> +    struct pmu_events_map *map);
>>>   int metricgroup__parse_groups_test(struct evlist *evlist,
>>>     struct pmu_events_map *map,
>>>     const char *str,
>>> -- 
>>> 2.26.2
>>>
>> .
>>
> 


Re: [PATCH v2 0/6] perf arm64 metricgroup support

2021-03-30 Thread kajoljain



On 3/30/21 2:37 AM, Paul A. Clarke wrote:
> On Fri, Mar 26, 2021 at 10:57:40AM +, John Garry wrote:
>> On 25/03/2021 20:39, Paul A. Clarke wrote:
>>> On Thu, Mar 25, 2021 at 06:33:12PM +0800, John Garry wrote:
 Metric reuse support is added for pmu-events parse metric testcase.
 This had been broken on power9 recentlty:
 https://lore.kernel.org/lkml/20210324015418.gc8...@li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com/
>>>
>>> Much better.  Before:
>>> --
>>> $ perf test -v 10 2>&1 | grep -i error | wc -l
>>> 112
>>> --
>>> After:
>>> --
>>> $ perf test -v 10 2>&1 | grep -i error | wc -l
>>> 17
>>> --
>>>
>>> And these seem like different types of issues:
>>> --
>>> $ perf test -v 10 2>&1 | grep -i error
>>> Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' 
>>> help '(null)'
>>> Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' 
>>> help '(null)'
>>> Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' 
>>> help '(null)'
>>> Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' 
>>> help '(null)'
>>> Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' 
>>> help '(null)'
>>> Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' 
>>> help '(null)'
>>> Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' 
>>> help '(null)'
>>> Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' 
>>> help '(null)'
>>> Error string 'Cannot find PMU `nest_powerbus0_imc'. Missing kernel 
>>> support?' help '(null)'
>>> Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' 
>>> help '(null)'
>>> Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' 
>>> help '(null)'
>>> Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' 
>>> help '(null)'
>>> Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' 
>>> help '(null)'
>>> Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' 
>>> help '(null)'
>>> Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' 
>>> help '(null)'
>>> Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' 
>>> help '(null)'
>>> Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' 
>>> help '(null)'
>>> --
>>>
>>
>> This looks suspicious.
>>
>> Firstly, does /sys/bus/event_source/devices/nest_mcs01_imc (or others,
>> above) exist on your system? I guess not.
>>
>> Secondly, checking Documentation/powerpc/imc.rst, we have examples of:
>> nest_mcs01/PM_MCS01_64B_R...
>>
>> So is the PMU name correct in the metric file for nest_mcs01_imc? Looking at
>> the kernel driver file, arch/powerpc/perf/imc-pmu.c, it seems to be correct.
>> Not sure.
> 
> I ran with a newer kernel, and the above errors disappeared, replaced with
> about 10 of:
> --
> Error string 'Cannot find PMU `hv_24x7'. Missing kernel support?' help 
> '(null)'
> --
> 
> ...but I was running without a hypervisor, so I tried the same kernel on a
> PowerVM-virtualized system and the "hv_24x7" messages went away, but the
> "nest" messages returned.  This may all be expected behavior... I confess
> I haven't followed these new perf capabilities closely.
> 

Hi Paul/John,
   This is something expected. For nest-imc we need bare-metal system and for
hv-24x7 we need VM environment. Since you are checking this test in VM machine,
there nest events are not supported and hence we are getting this error.

Thanks,
Kajol Jain

> It's extremely likely that none of these errors has anything to do with your
> changes. :-
> 
> PC
> 


Re: [PATCH] perf tools: Remove redundant code

2021-03-11 Thread kajoljain



On 3/10/21 8:48 AM, Jiapeng Chong wrote:
> Fix the following coccicheck warnings:
> 
> ./tools/perf/util/evlist.c:1315:5-8: Unneeded variable: "err". Return "-
> ENOMEM" on line 1340.
> 
> Reported-by: Abaci Robot 
> Signed-off-by: Jiapeng Chong 
> ---
>  tools/perf/util/evlist.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
> index 882cd1f..6c2a271 100644
> --- a/tools/perf/util/evlist.c
> +++ b/tools/perf/util/evlist.c
> @@ -1313,7 +1313,6 @@ static int evlist__create_syswide_maps(struct evlist 
> *evlist)
>  {
>   struct perf_cpu_map *cpus;
>   struct perf_thread_map *threads;
> - int err = -ENOMEM;
>  
>   /*
>* Try reading /sys/devices/system/cpu/online to get
> @@ -1338,7 +1337,7 @@ static int evlist__create_syswide_maps(struct evlist 
> *evlist)
>  out_put:
>   perf_cpu_map__put(cpus);
>  out:
> - return err;
> + return -ENOMEM;
>  }

Seems fine to me.

Reviewed-By: Kajol Jain
Thanks,
Kajol Jain
>  
>  int evlist__open(struct evlist *evlist)
> 


Re: [PATCH v3 1/2] powerpc/perf: Use PVR rather than oprofile field to determine CPU version

2021-03-03 Thread kajoljain



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] perf stat: improve readability of shadow stats

2021-03-02 Thread kajoljain



On 3/1/21 10:54 PM, Changbin Du wrote:
> This does follow two changes:
>   1) Select appropriate unit between K/M/G.
>   2) Use 'cpu-sec' instead of 'sec' to state this is not the wall-time.
> 
> $ sudo ./perf stat -a -- sleep 1
> 
> Before: Unit 'M' is selected even the number is very small.
>  Performance counter stats for 'system wide':
> 
>   4,003.06 msec cpu-clock #3.998 CPUs utilized
> 16,179  context-switches  #0.004 M/sec
>161  cpu-migrations#0.040 K/sec
>  4,699  page-faults   #0.001 M/sec
>  6,135,801,925  cycles#1.533 GHz  
> (83.21%)
>  5,783,308,491  stalled-cycles-frontend   #   94.26% frontend cycles 
> idle (83.21%)
>  4,543,694,050  stalled-cycles-backend#   74.05% backend cycles 
> idle  (66.49%)
>  4,720,130,587  instructions  #0.77  insn per cycle
>   #1.23  stalled cycles 
> per insn  (83.28%)
>753,848,078  branches  #  188.318 M/sec
> (83.61%)
> 37,457,747  branch-misses #4.97% of all branches  
> (83.48%)
> 
>1.001283725 seconds time elapsed
> 
> After:
> $ sudo ./perf stat -a -- sleep 2
> 
>  Performance counter stats for 'system wide':
> 
>   8,003.20 msec cpu-clock #3.998 CPUs utilized
>  9,768  context-switches  #1.221 K/cpu-sec
>164  cpu-migrations#   20.492  /cpu-sec
> 74,146  page-faults   #9.265 K/cpu-sec
> 19,008,796,806  cycles#2.375 GHz  
> (83.21%)
> 14,789,443,853  stalled-cycles-frontend   #   77.80% frontend cycles 
> idle (83.29%)
> 11,867,812,064  stalled-cycles-backend#   62.43% backend cycles 
> idle  (66.80%)
>  9,898,252,603  instructions  #0.52  insn per cycle
>   #1.49  stalled cycles 
> per insn  (83.41%)
>  2,063,251,998  branches  #  257.803 M/cpu-sec
> (83.41%)
> 86,941,704  branch-misses #4.21% of all branches  
> (83.30%)
> 
>2.001743706 seconds time elapsed
> 
> Signed-off-by: Changbin Du 
> ---
>  tools/perf/util/stat-shadow.c | 13 +
>  tools/perf/util/units.c   | 22 ++
>  tools/perf/util/units.h   |  1 +
>  3 files changed, 28 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
> index 6ccf21a72f06..786b5ef512d8 100644
> --- a/tools/perf/util/stat-shadow.c
> +++ b/tools/perf/util/stat-shadow.c
> @@ -9,6 +9,7 @@
>  #include "expr.h"
>  #include "metricgroup.h"
>  #include "cgroup.h"
> +#include "units.h"
>  #include 
>  

>  /*
> @@ -1270,18 +1271,14 @@ void perf_stat__print_shadow_stats(struct 
> perf_stat_config *config,
>   generic_metric(config, evsel->metric_expr, 
> evsel->metric_events, NULL,
>   evsel->name, evsel->metric_name, NULL, 1, cpu, 
> out, st);
>   } else if (runtime_stat_n(st, STAT_NSECS, cpu, ) != 0) {
> - char unit = 'M';
> + char unit = ' ';
>   char unit_buf[10];
>  
>   total = runtime_stat_avg(st, STAT_NSECS, cpu, );
> -
>   if (total)
> - ratio = 1000.0 * avg / total;
> - if (ratio < 0.001) {
> - ratio *= 1000;
> - unit = 'K';
> - }
> - snprintf(unit_buf, sizeof(unit_buf), "%c/sec", unit);
> + ratio = convert_unit_double(10.0 * avg / total, 
> );
> +
> + snprintf(unit_buf, sizeof(unit_buf), "%c/cpu-sec", unit);
>   print_metric(config, ctxp, NULL, "%8.3f", unit_buf, ratio);
>   } else if (perf_stat_evsel__is(evsel, SMI_NUM)) {
>   print_smi_cost(config, cpu, out, st, );
> diff --git a/tools/perf/util/units.c b/tools/perf/util/units.c
> index a46762aec4c9..ac13b5ecde31 100644
> --- a/tools/perf/util/units.c
> +++ b/tools/perf/util/units.c
> @@ -55,6 +55,28 @@ unsigned long convert_unit(unsigned long value, char *unit)
>   return value;
>  }
>

Hi Changbin,
  Since we are using added function `convert_unit_double` just in 
stat-shadow.c,
I think there is no need to add it in units.h, we can directly create static 
func inside `stat-shadow.c`itself.

Thanks,
Kajol Jain
  
> +double convert_unit_double(double value, char *unit)
> +{
> + *unit = ' ';
> +
> + if (value > 1000.0) {
> + value /= 1000.0;
> + *unit = 'K';
> + }
> +
> + if (value > 1000.0) {
> + value /= 1000.0;
> + 

Re: [PATCH] [perf] powerpc: Remove unsupported metrics

2021-02-25 Thread kajoljain



On 2/24/21 11:44 PM, Paul A. Clarke wrote:
> Several metrics are defined based on unsupported / non-existent
> events, and silently discarded.  Remove them for good code hygiene
> and to avoid confusion.
> 

Hi Paul,
  Thanks for the patch. Changes looks good to me.

Reviewed-by: Kajol Jain

Thanks,
Kajol Jain

> Signed-off-by: Paul A. Clarke 
> ---
>  .../arch/powerpc/power9/metrics.json  | 132 --
>  1 file changed, 132 deletions(-)
> 
> diff --git a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json 
> b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
> index f8784c608479..140402d2855f 100644
> --- a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
> +++ b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
> @@ -1209,156 +1209,24 @@
>  "MetricGroup": "instruction_stats_percent_per_ref",
>  "MetricName": "inst_from_rmem_percent"
>  },
> -{
> -"BriefDescription": "%L2 Modified CO Cache read Utilization (4 pclks 
> per disp attempt)",
> -"MetricExpr": "((PM_L2_CASTOUT_MOD/2)*4)/ PM_RUN_CYC * 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_co_m_rd_util"
> -},
> -{
> -"BriefDescription": "L2 dcache invalidates per run inst (per core)",
> -"MetricExpr": "(PM_L2_DC_INV / 2) / PM_RUN_INST_CMPL * 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_dc_inv_rate_percent"
> -},
>  {
>  "BriefDescription": "Demand load misses as a % of L2 LD dispatches 
> (per thread)",
>  "MetricExpr": "PM_L1_DCACHE_RELOAD_VALID / (PM_L2_LD / 2) * 100",
>  "MetricGroup": "l2_stats",
>  "MetricName": "l2_dem_ld_disp_percent"
>  },
> -{
> -"BriefDescription": "L2 Icache invalidates per run inst (per core)",
> -"MetricExpr": "(PM_L2_IC_INV / 2) / PM_RUN_INST_CMPL * 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_ic_inv_rate_percent"
> -},
> -{
> -"BriefDescription": "L2 Inst misses as a % of total L2 Inst 
> dispatches (per thread)",
> -"MetricExpr": "PM_L2_INST_MISS / PM_L2_INST * 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_inst_miss_ratio_percent"
> -},
> -{
> -"BriefDescription": "Average number of cycles between L2 Load hits",
> -"MetricExpr": "(PM_L2_LD_HIT / PM_RUN_CYC) / 2",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_ld_hit_frequency"
> -},
> -{
> -"BriefDescription": "Average number of cycles between L2 Load 
> misses",
> -"MetricExpr": "(PM_L2_LD_MISS / PM_RUN_CYC) / 2",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_ld_miss_frequency"
> -},
> -{
> -"BriefDescription": "L2 Load misses as a % of total L2 Load 
> dispatches (per thread)",
> -"MetricExpr": "PM_L2_LD_MISS / PM_L2_LD * 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_ld_miss_ratio_percent"
> -},
> -{
> -"BriefDescription": "% L2 load disp attempts Cache read Utilization 
> (4 pclks per disp attempt)",
> -"MetricExpr": "((PM_L2_RCLD_DISP/2)*4)/ PM_RUN_CYC * 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_ld_rd_util"
> -},
> -{
> -"BriefDescription": "L2 load misses that require a cache write (4 
> pclks per disp attempt) % of pclks",
> -"MetricExpr": "((( PM_L2_LD_DISP - PM_L2_LD_HIT)/2)*4)/ PM_RUN_CYC * 
> 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_ldmiss_wr_util"
> -},
> -{
> -"BriefDescription": "L2 local pump prediction success",
> -"MetricExpr": "PM_L2_LOC_GUESS_CORRECT / (PM_L2_LOC_GUESS_CORRECT + 
> PM_L2_LOC_GUESS_WRONG) * 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_local_pred_correct_percent"
> -},
> -{
> -"BriefDescription": "L2 COs that were in M,Me,Mu state as a % of all 
> L2 COs",
> -"MetricExpr": "PM_L2_CASTOUT_MOD / (PM_L2_CASTOUT_MOD + 
> PM_L2_CASTOUT_SHR) * 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_mod_co_percent"
> -},
> -{
> -"BriefDescription": "% of L2 Load RC dispatch atampts that failed 
> because of address collisions and cclass conflicts",
> -"MetricExpr": "(PM_L2_RCLD_DISP_FAIL_ADDR )/ PM_L2_RCLD_DISP * 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_rc_ld_disp_addr_fail_percent"
> -},
> -{
> -"BriefDescription": "% of L2 Load RC dispatch attempts that failed",
> -"MetricExpr": "(PM_L2_RCLD_DISP_FAIL_ADDR + 
> PM_L2_RCLD_DISP_FAIL_OTHER)/ PM_L2_RCLD_DISP * 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_rc_ld_disp_fail_percent"
> -},
> -{
> -"BriefDescription": "% of L2 Store RC dispatch atampts that failed 
> because of address collisions and cclass conflicts",
> -"MetricExpr": 

Re: [PATCH] perf machine: Use true and false for bool variable

2021-02-18 Thread kajoljain



On 2/18/21 2:54 PM, Jiapeng Chong wrote:
> Fix the following coccicheck warnings:
> 
> ./tools/perf/util/machine.c:2000:9-10: WARNING: return of 0/1 in
> function 'symbol__match_regex' with return type bool.
> 
> Reported-by: Abaci Robot 
> Signed-off-by: Jiapeng Chong 
> ---
>  tools/perf/util/machine.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> index 1e9d3f9..f7ee29b 100644
> --- a/tools/perf/util/machine.c
> +++ b/tools/perf/util/machine.c
> @@ -1997,8 +1997,8 @@ int machine__process_event(struct machine *machine, 
> union perf_event *event,
>  static bool symbol__match_regex(struct symbol *sym, regex_t *regex)
>  {
>   if (!regexec(regex, sym->name, 0, NULL, 0))
> - return 1;
> - return 0;
> + return true;
> + return false;
>  }
>  

Hi Jiapeng,
   Just a suggestion, Can we make this check in single line like this:

static bool symbol__match_regex(struct symbol *sym, regex_t *regex)
{
return regexec(regex, sym->name, 0, NULL, 0) == 0;
}

Thanks,
Kajol Jain

>  static void ip__resolve_ams(struct thread *thread,
> 


Re: [PATCH RFC v5 00/13] perf pmu-events: Support event aliasing for system PMUs

2020-11-28 Thread kajoljain



On 11/6/20 6:05 PM, John Garry wrote:
> Currently event aliasing and metrics for only CPU and uncore PMUs is
> supported. In fact, only uncore PMUs aliasing is supported for when the
> uncore PMUs are fixed for a CPU, which may not always be the case for
> certain architectures.
> 
> This series adds support for PMU event aliasing and metrics for system and
> other uncore PMUs which are not tied to a specific CPU.
> 
> For this, we introduce system event tables in generated pmu-events.c,
> which contain a per-SoC table of events of all its system PMUs. Each
> per-PMU event is matched by a "COMPAT" property.
> 
> When creating aliased and metrics PMUs, we treat core/uncore and
> system PMUs differently:
> 
> - For CPU PMUs, we always match for the event mapfile based on the CPUID.
>   This has not changed.
> 
> - For an system PMUs, we iterate through all the events in all the system
>   PMU tables.
> 
>   Matches are based on the "COMPAT" property matching the PMU sysfs
>   identifier contents, in /sys/bus/event_source/devices//identifier
> 
>   Uncore PMUs, may be matched via CPUID or same as system PMU, depending
>   on whether the uncore PMU is tied to a specific CPUID.
> 
> Initial reference support is also added for ARM SMMUv3 PMCG (Performance
> Monitor Event Group) PMU for HiSilicon hip09 platform with only a single
> event so far - see driver in drivers/perf/arm_smmuv3_pmu.c reference.
> 
> Here is a sample output with this series on Huawei D06CS board:
> 
> root@ubuntu:/# ./perf list
>[...]
> 
> smmu v3 pmcg:
>smmuv3_pmcg.config_cache_miss
> [Configuration cache miss caused by transaction or(ATS or
> non-ATS)translation request. Unit: smmuv3_pmcg]
>smmuv3_pmcg.config_struct_access
> [Configuration structure access. Unit: smmuv3_pmcg]
>smmuv3_pmcg.cycles
> [Clock cycles. Unit: smmuv3_pmcg]
>smmuv3_pmcg.l1_tlb
> [SMMUv3 PMCG L1 TABLE transation. Unit: smmuv3_pmcg]
>smmuv3_pmcg.pcie_ats_trans_passed
> [PCIe ATS Translated Transaction passed through SMMU. Unit:
> smmuv3_pmcg]
>smmuv3_pmcg.pcie_ats_trans_rq
> [PCIe ATS Translation Request received. Unit: smmuv3_pmcg]
>smmuv3_pmcg.tlb_miss
> [TLB miss caused by incoming transaction or (ATS or non-ATS) 
> translation request. Unit: smmuv3_pmcg]
>smmuv3_pmcg.trans_table_walk_access
> [Translation table walk access. Unit: smmuv3_pmcg]
>smmuv3_pmcg.transaction
> [Transaction. Unit: smmuv3_pmcg]
> 
> root@ubuntu:/# ./perf stat -v -e smmuv3_pmcg.l1_tlb sleep 1
> Using CPUID 0x480fd010
> -> smmuv3_pmcg_200100020/event=0x8a/
> -> smmuv3_pmcg_200140020/event=0x8a/
> -> smmuv3_pmcg_100020/event=0x8a/
> -> smmuv3_pmcg_140020/event=0x8a/
> -> smmuv3_pmcg_200148020/event=0x8a/
> -> smmuv3_pmcg_148020/event=0x8a/
> smmuv3_pmcg.l1_tlb: 0 1001221690 1001221690
> smmuv3_pmcg.l1_tlb: 0 1001220090 1001220090
> smmuv3_pmcg.l1_tlb: 101 1001219660 1001219660
> smmuv3_pmcg.l1_tlb: 0 1001219010 1001219010
> smmuv3_pmcg.l1_tlb: 0 1001218360 1001218360
> smmuv3_pmcg.l1_tlb: 134 1001217850 1001217850
> 
> Performance counter stats for 'system wide':
> 
> 235  smmuv3_pmcg.l1_tlb 
> 
> 1.001263128 seconds time elapsed
> 
> root@ubuntu:/#
> 
> Support is also added for imx8mm DDR PMU and HiSilicon hip09 uncore events.
> Some events for hip09 may not be accurate at the moment.
> 
> Series is here:
> https://github.com/hisilicon/kernel-dev/tree/private-topic-perf-5.10-sys-pmu-events-v5
> 
> Kernel part is here:
> https://lore.kernel.org/lkml/1602149181-237415-1-git-send-email-john.ga...@huawei.com/T/#mc34f758ab72f3d4a90d854b9bda7e6bbb90835b2
> 
> Differences to v4:
> - Drop hack for fixing metrics containing aliases which match multiple
>   PMUs, and add a proper fix attempt
> - Rebase to acme perf/core from 30 Oct
> - Fix up imx8 event names according to request from Joakim
> 
> Differences to v3:
> - Rebase to v5.9-rc7
> - Includes Ian's uncore metric expressions Fix and another fix
> - Add hip09 uncore events
> - Tidy jevents.c changes a bit
> 
> Differences to v2:
> - fixups for imx8mm JSONs
> - fix for metrics being repeated per PMU
> - use sysfs__read_str()
> - fix typo in PMCG JSON
> - drop evsel fix, which someone else fixed
> 
> Differences to v1:
> - Stop using SoC id and use a per-PMU identifier instead
> - Add metric group sys events support
>- This is a bit hacky
> - Add imx8mm DDR Perf support
> - Add fix for parse events sel
>   - without it, I get this spewed for metric event:
> 
>   assertion failed at util/parse-events.c:1637
> 
> Joakim Zhang (1):
>   perf vendor events: Add JSON metrics for imx8mm DDR Perf
> 
> John Garry (12):
>   perf jevents: Add support for an extra directory level
>   perf jevents: Add support for system events tables
>   perf pmu: Add pmu_id()
>   perf pmu: Add pmu_add_sys_aliases()
>   perf vendor events arm64: Add Architected events smmuv3-pmcg.json
>   perf vendor events 

Re: [PATCH] perf test: Omit test 68 for s390.

2020-11-19 Thread kajoljain



On 11/4/20 1:59 PM, Thomas Richter wrote:
> Commit ed21d6d7c48e6e ("perf tests: Add test for PE binary format support")
> adds a WINDOWS EXE file named tests/pe-file.exe, which is
> examined by the test case 'PE file support'.
> 
> This test reads the buildid from the file tests/pe-file.exe,
> which is a Portable Executable (PE) binary file used by the
> Windows operating system.
> 
> Since s390 does not support PE files, omit this test.
> 
> Output before:
> [root@t35lp46 perf]# ./perf test -F 68
> 68: PE file support   : Failed!
> [root@t35lp46 perf]#
> 
> Output after:
> [root@t35lp46 perf]# ./perf test -F 68
> 68: PE file support   : Skip
> [root@t35lp46 perf]#
> 
> 

Patch looks good to me. Thanks for correcting it. Since in powerpc also we are 
having similar issue,
I send patch on top of this change. 

Reviewed-By: Kajol Jain

Thanks,
Kajol Jain

> Signed-off-by: Thomas Richter 
> ---
>  tools/perf/tests/pe-file-parsing.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/perf/tests/pe-file-parsing.c 
> b/tools/perf/tests/pe-file-parsing.c
> index 58b90c42eb38..4e45178c50f6 100644
> --- a/tools/perf/tests/pe-file-parsing.c
> +++ b/tools/perf/tests/pe-file-parsing.c
> @@ -18,7 +18,7 @@
>  
>  #include "tests.h"
>  
> -#ifdef HAVE_LIBBFD_SUPPORT
> +#if defined(HAVE_LIBBFD_SUPPORT) && !defined(__s390x__)
>  
>  static int run_dir(const char *d)
>  {
> 


Re: [PATCH RFC v5 01/13] perf jevents: Add support for an extra directory level

2020-11-17 Thread kajoljain



On 11/13/20 2:54 PM, John Garry wrote:
> On 13/11/2020 08:48, kajoljain wrote:
>>
>> On 11/6/20 6:05 PM, John Garry wrote:
>>> Currently only upto a level 2 directory is supported, in form
>>> vendor/platform.
>> Hi John,
>>  Just want to check in case of sub directories,
>> Will it be good add on/feasible to be able to include events of particular 
>> sub-directory for a
>> platform? Otherwise with this patch in the end all event will be part of
>> same pmu_event structure. So what is the purpose of sub directories? Let me 
>> know if I am missing something.
> 
> Hi Kajol Jain,
> 
> So currently we support both of the following structure:
> arch/platform
> arch/vendor/platform/
> 
> arch/vendor/platform/ is for an arch like arm, where the arch provider may 
> not be the vendor.
> 
> I want to go one step further, to support also:
> arch/vendor/platform/cpu
> arch/vendor/platform/sys
> 
> Here we have separate folders for cpu and sys events. CPU events in "cpu" 
> folder are added to pmu_events_map[], as before. And events in "sys" folder 
> are added from patch 2/13 to new table pmu_sys_events_table[].
> 
> I hope it's clearer now.

Hi John,
Thanks for explaining. This patch looks good to me then.

Reviewed-By: Kajol Jain

Thanks,
Kajol Jain
> 
> Thanks,
> John
> 
>>
>> Thanks,
>> Kajol Jain
>>> Add support for a further level, to support vendor/platform
>>> sub-directories in future.
> 


Re: [PATCH RFC v5 01/13] perf jevents: Add support for an extra directory level

2020-11-13 Thread kajoljain



On 11/6/20 6:05 PM, John Garry wrote:
> Currently only upto a level 2 directory is supported, in form
> vendor/platform.

Hi John,
Just want to check in case of sub directories,
Will it be good add on/feasible to be able to include events of particular 
sub-directory for a
platform? Otherwise with this patch in the end all event will be part of
same pmu_event structure. So what is the purpose of sub directories? Let me 
know if I am missing something.

Thanks,
Kajol Jain
> 
> Add support for a further level, to support vendor/platform
> sub-directories in future.
> 
> Signed-off-by: John Garry 
> ---
>  tools/perf/pmu-events/jevents.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
> index 72cfa3b5046d..9022216b1253 100644
> --- a/tools/perf/pmu-events/jevents.c
> +++ b/tools/perf/pmu-events/jevents.c
> @@ -978,15 +978,20 @@ static int process_one_file(const char *fpath, const 
> struct stat *sb,
>   int level   = ftwbuf->level;
>   int err = 0;
>  
> - if (level == 2 && is_dir) {
> + if (level >= 2 && is_dir) {
> + int count = 0;
>   /*
>* For level 2 directory, bname will include parent name,
>* like vendor/platform. So search back from platform dir
>* to find this.
> +  * Something similar for level 3 directory, but we're a PMU
> +  * category folder, like vendor/platform/cpu.
>*/
>   bname = (char *) fpath + ftwbuf->base - 2;
>   for (;;) {
>   if (*bname == '/')
> + count++;
> + if (count == level - 1)
>   break;
>   bname--;
>   }
> @@ -999,13 +1004,13 @@ static int process_one_file(const char *fpath, const 
> struct stat *sb,
>level, sb->st_size, bname, fpath);
>  
>   /* base dir or too deep */
> - if (level == 0 || level > 3)
> + if (level == 0 || level > 4)
>   return 0;
>  
>  
>   /* model directory, reset topic */
>   if ((level == 1 && is_dir && is_leaf_dir(fpath)) ||
> - (level == 2 && is_dir)) {
> + (level >= 2 && is_dir && is_leaf_dir(fpath))) {
>   if (close_table)
>   print_events_table_suffix(eventsfp);
>  
> 


Re: [perf metricgroup] fcc9c5243c: perf-sanity-tests.Parse_and_process_metrics.fail

2020-11-03 Thread kajoljain



On 11/3/20 10:24 PM, John Garry wrote:
> On 03/11/2020 16:05, Ian Rogers wrote:
>> On Tue, Nov 3, 2020 at 6:43 AM John Garry  wrote:
>>> On 20/10/2020 17:53, Ian Rogers wrote:
>> Thanks for taking a look John. If you want help you can send the
>> output of "perf test 67 -vvv" to me. It is possible Broadwell has
>> similar glitches in the json to Skylake. I tested the original test on
>> server parts as I can access them as cloud machines.
>>
>>> I will have a look, but I was hoping that Ian would have a proper fix
>>> for this on top of ("perf metricgroup: Fix uncore metric expressions"),
>>> which now looks to be merged.
>> I still have these changes to look at in my inbox but I'm assuming
>> they're good:-)  Sorry for not getting to them, but it's good they are
>> merged.
> Hi Ian,
>  Checked in upstream kernel with your fix patch, in powerpc also test 
> case 67 is passing.
> But I am getting issue in test 10 for powerpc
>
> [command]# ./perf test 10
> 10: PMU events  :
> 10.1: PMU event table sanity    : Ok
> 10.2: PMU event map aliases : Ok
> 10.3: Parsing of PMU event table metrics    : 
> Skip (some metrics failed)
> 10.4: Parsing of PMU event table metrics with fake PMUs : 
> FAILED!
>
> Was debugging it, issue is with commit e1c92a7fbbc5 perf tests: Add 
> another metric parsing test.
>
> So, there we are passing different runtime parameter value in 
> "expr__find_other and expr__parse"
> in function `metric_parse_fake`. I believe we need to send same value.
> I will send fix patch for the same.
>>> Just wondering, was a patch ever submitted for this? Something still
>>> broken? I can't see any recent relevant changes to tests/pmu-events.c
>> The test itself shouldn't have changed, but the json files parsed by
>> jevents and turned into C code that the test exercises should have
>> changed. Jin Yao has sent two patch sets fixing a metric issue on SKL
>> (Skylake non-server) that should hopefully fix the issue there - I'll
>> check the status on these. Are you testing on Skylake?
> 
> So I have re-read this thread, and it seems that 2x different things are 
> being discussed:
> a. some breakage for test #10 on skylake
> b. test #67 being broken
> 
> It seems that a. has been addressed. That's what I was asking about just now.

Hi Ian/John,
The breakage for test #10 which I mentioned is for power9 machine, if 
that you were asking.
I still need to send fix patch out. I will send it soon.

Thanks,
Kajol Jain

> 
> So about b., which I thought may be broken for some other reason apart from 
> my hacky patch. But it seems not the case, and a proper patch is needed there.
> 
> Ian, have you had a chance to consider this issue in b.? That is, we have 
> breakage for metrics using uncore alias expressions for when multiple uncore 
> PMUs associated exist in the system? As before, looks broken by ded80bda8bc9 
> ("perf expr: Migrate expr ids table to a hashmap")
> 
> Thanks,
> John
> 
> 


Re: [PATCH] memstick: mspro_block: remove unneeded semicolon

2020-11-02 Thread kajoljain



On 11/2/20 7:12 PM, Tom Rix wrote:
> 
> On 11/1/20 10:51 PM, kajoljain wrote:
>>
>> On 10/31/20 7:18 PM, t...@redhat.com wrote:
>>> From: Tom Rix 
>>>
>>> A semicolon is not needed after a switch statement.
>> Hi Tom,
>>I was checking this patch. Not sure if it will come under as fix patch. 
>> Since this is not fixing
>> any logical issue do we still need to add fix tag?
> 
> My rule of thumb is a fix means the kernel needs to be recompiled.

Yes make sense. Thanks for confirming.

Thanks,
Kajol Jain

> 
> This isn't a fix.
> 
> Tom
> 
>>
>> Thanks,
>> Kajol Jain
>>> Signed-off-by: Tom Rix 
>>> ---
>>>  drivers/memstick/core/mspro_block.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/memstick/core/mspro_block.c 
>>> b/drivers/memstick/core/mspro_block.c
>>> index cd6b8d4f2335..afb892e7ffc6 100644
>>> --- a/drivers/memstick/core/mspro_block.c
>>> +++ b/drivers/memstick/core/mspro_block.c
>>> @@ -276,7 +276,7 @@ static const char *mspro_block_attr_name(unsigned char 
>>> tag)
>>> return "attr_devinfo";
>>> default:
>>> return NULL;
>>> -   };
>>> +   }
>>>  }
>>>  
>>>  typedef ssize_t (*sysfs_show_t)(struct device *dev,
>>>
> 


Re: [PATCH] memstick: mspro_block: remove unneeded semicolon

2020-11-01 Thread kajoljain



On 10/31/20 7:18 PM, t...@redhat.com wrote:
> From: Tom Rix 
> 
> A semicolon is not needed after a switch statement.

Hi Tom,
   I was checking this patch. Not sure if it will come under as fix patch. 
Since this is not fixing
any logical issue do we still need to add fix tag?

Thanks,
Kajol Jain
> 
> Signed-off-by: Tom Rix 
> ---
>  drivers/memstick/core/mspro_block.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/memstick/core/mspro_block.c 
> b/drivers/memstick/core/mspro_block.c
> index cd6b8d4f2335..afb892e7ffc6 100644
> --- a/drivers/memstick/core/mspro_block.c
> +++ b/drivers/memstick/core/mspro_block.c
> @@ -276,7 +276,7 @@ static const char *mspro_block_attr_name(unsigned char 
> tag)
>   return "attr_devinfo";
>   default:
>   return NULL;
> - };
> + }
>  }
>  
>  typedef ssize_t (*sysfs_show_t)(struct device *dev,
> 


Re: [PATCH v2 2/2] perf jevents: Add test for arch std events

2020-10-23 Thread kajoljain



On 10/22/20 4:32 PM, John Garry wrote:
> Recently there was an undetected breakage for std arch event support.
> 
> Add support in "PMU events" testcase to detect such breakages.
> 
> For this, the "test" arch needs has support added to process std arch
> events. And a test event is added for the test, ifself.
> 
> Also add a few code comments to help understand the code a bit better.

Patch looks good to me.

Reviewed-By: Kajol Jain

Thanks,
Kajol Jain
> 
> Signed-off-by: John Garry 
> ---
>  .../perf/pmu-events/arch/test/arch-std-events.json |  8 
>  .../perf/pmu-events/arch/test/test_cpu/cache.json  |  5 +
>  tools/perf/pmu-events/jevents.c|  4 
>  tools/perf/tests/pmu-events.c  | 14 ++
>  4 files changed, 31 insertions(+)
>  create mode 100644 tools/perf/pmu-events/arch/test/arch-std-events.json
>  create mode 100644 tools/perf/pmu-events/arch/test/test_cpu/cache.json
> 
> diff --git a/tools/perf/pmu-events/arch/test/arch-std-events.json 
> b/tools/perf/pmu-events/arch/test/arch-std-events.json
> new file mode 100644
> index ..43f6f729d6ae
> --- /dev/null
> +++ b/tools/perf/pmu-events/arch/test/arch-std-events.json
> @@ -0,0 +1,8 @@
> +[
> +{
> +"PublicDescription": "Attributable Level 3 cache access, read",
> +"EventCode": "0x40",
> +"EventName": "L3_CACHE_RD",
> +"BriefDescription": "L3 cache access, read"
> +}
> +]
> diff --git a/tools/perf/pmu-events/arch/test/test_cpu/cache.json 
> b/tools/perf/pmu-events/arch/test/test_cpu/cache.json
> new file mode 100644
> index ..036d0efdb2bb
> --- /dev/null
> +++ b/tools/perf/pmu-events/arch/test/test_cpu/cache.json
> @@ -0,0 +1,5 @@
> +[
> +{
> +  "ArchStdEvent": "L3_CACHE_RD"
> +}
> +]
> \ No newline at end of file
> diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
> index 7326c14c4623..72cfa3b5046d 100644
> --- a/tools/perf/pmu-events/jevents.c
> +++ b/tools/perf/pmu-events/jevents.c
> @@ -1162,6 +1162,10 @@ int main(int argc, char *argv[])
>  
>   sprintf(ldirname, "%s/test", start_dirname);
>  
> + rc = nftw(ldirname, preprocess_arch_std_files, maxfds, 0);
> + if (rc)
> + goto err_processing_std_arch_event_dir;
> +
>   rc = nftw(ldirname, process_one_file, maxfds, 0);
>   if (rc)
>   goto err_processing_dir;
> diff --git a/tools/perf/tests/pmu-events.c b/tools/perf/tests/pmu-events.c
> index d3517a74d95e..ad2b21591275 100644
> --- a/tools/perf/tests/pmu-events.c
> +++ b/tools/perf/tests/pmu-events.c
> @@ -14,8 +14,10 @@
>  #include "util/parse-events.h"
>  
>  struct perf_pmu_test_event {
> + /* used for matching against events from generated pmu-events.c */
>   struct pmu_event event;
>  
> + /* used for matching against event aliases */
>   /* extra events for aliases */
>   const char *alias_str;
>  
> @@ -78,6 +80,17 @@ static struct perf_pmu_test_event test_cpu_events[] = {
>   .alias_str = "umask=0,(null)=0x30d40,event=0x3a",
>   .alias_long_desc = "Number of Enhanced Intel SpeedStep(R) 
> Technology (EIST) transitions",
>   },
> + {
> + .event = {
> + .name = "l3_cache_rd",
> + .event = "event=0x40",
> + .desc = "L3 cache access, read",
> + .long_desc = "Attributable Level 3 cache access, read",
> + .topic = "cache",
> + },
> + .alias_str = "event=0x40",
> + .alias_long_desc = "Attributable Level 3 cache access, read",
> + },
>   { /* sentinel */
>   .event = {
>   .name = NULL,
> @@ -357,6 +370,7 @@ static int __test__pmu_event_aliases(char *pmu_name, int 
> *count)
>  }
>  
>  
> +/* Test that aliases generated are as expected */
>  static int test_aliases(void)
>  {
>   struct perf_pmu *pmu = NULL;
> 


Re: [PATCH v2 1/2] perf jevents: Tidy error handling

2020-10-23 Thread kajoljain



On 10/22/20 4:32 PM, John Garry wrote:
> There is much duplication in the error handling for directory transvering
> for prcessing JSONs.
> 
> Factor out the common code to tidy a bit.
> 

Patch looks good to me.

Reviewed-By: Kajol Jain

Thanks,
Kajol Jain
> Signed-off-by: John Garry 
> ---
>  tools/perf/pmu-events/jevents.c | 83 ++---
>  1 file changed, 35 insertions(+), 48 deletions(-)
> 
> diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
> index e47644cab3fa..7326c14c4623 100644
> --- a/tools/perf/pmu-events/jevents.c
> +++ b/tools/perf/pmu-events/jevents.c
> @@ -1100,12 +1100,13 @@ static int process_one_file(const char *fpath, const 
> struct stat *sb,
>   */
>  int main(int argc, char *argv[])
>  {
> - int rc, ret = 0;
> + int rc, ret = 0, empty_map = 0;
>   int maxfds;
>   char ldirname[PATH_MAX];
>   const char *arch;
>   const char *output_file;
>   const char *start_dirname;
> + char *err_string_ext = "";
>   struct stat stbuf;
>  
>   prog = basename(argv[0]);
> @@ -1133,7 +1134,8 @@ int main(int argc, char *argv[])
>   /* If architecture does not have any event lists, bail out */
>   if (stat(ldirname, ) < 0) {
>   pr_info("%s: Arch %s has no PMU event lists\n", prog, arch);
> - goto empty_map;
> + empty_map = 1;
> + goto err_close_eventsfp;
>   }
>  
>   /* Include pmu-events.h first */
> @@ -1150,75 +1152,60 @@ int main(int argc, char *argv[])
>*/
>  
>   maxfds = get_maxfds();
> - mapfile = NULL;
>   rc = nftw(ldirname, preprocess_arch_std_files, maxfds, 0);
> - if (rc && verbose) {
> - pr_info("%s: Error preprocessing arch standard files %s\n",
> - prog, ldirname);
> - goto empty_map;
> - } else if (rc < 0) {
> - /* Make build fail */
> - fclose(eventsfp);
> - free_arch_std_events();
> - return 1;
> - } else if (rc) {
> - goto empty_map;
> - }
> + if (rc)
> + goto err_processing_std_arch_event_dir;
>  
>   rc = nftw(ldirname, process_one_file, maxfds, 0);
> - if (rc && verbose) {
> - pr_info("%s: Error walking file tree %s\n", prog, ldirname);
> - goto empty_map;
> - } else if (rc < 0) {
> - /* Make build fail */
> - fclose(eventsfp);
> - free_arch_std_events();
> - ret = 1;
> - goto out_free_mapfile;
> - } else if (rc) {
> - goto empty_map;
> - }
> + if (rc)
> + goto err_processing_dir;
>  
>   sprintf(ldirname, "%s/test", start_dirname);
>  
>   rc = nftw(ldirname, process_one_file, maxfds, 0);
> - if (rc && verbose) {
> - pr_info("%s: Error walking file tree %s rc=%d for test\n",
> - prog, ldirname, rc);
> - goto empty_map;
> - } else if (rc < 0) {
> - /* Make build fail */
> - free_arch_std_events();
> - ret = 1;
> - goto out_free_mapfile;
> - } else if (rc) {
> - goto empty_map;
> - }
> + if (rc)
> + goto err_processing_dir;
>  
>   if (close_table)
>   print_events_table_suffix(eventsfp);
>  
>   if (!mapfile) {
>   pr_info("%s: No CPU->JSON mapping?\n", prog);
> - goto empty_map;
> + empty_map = 1;
> + goto err_close_eventsfp;
>   }
>  
> - if (process_mapfile(eventsfp, mapfile)) {
> + rc = process_mapfile(eventsfp, mapfile);
> + fclose(eventsfp);
> + if (rc) {
>   pr_info("%s: Error processing mapfile %s\n", prog, mapfile);
>   /* Make build fail */
> - fclose(eventsfp);
> - free_arch_std_events();
>   ret = 1;
> + goto err_out;
>   }
>  
> + free_arch_std_events();
> + free(mapfile);
> + return 0;
>  
> - goto out_free_mapfile;
> -
> -empty_map:
> +err_processing_std_arch_event_dir:
> + err_string_ext = " for std arch event";
> +err_processing_dir:
> + if (verbose) {
> + pr_info("%s: Error walking file tree %s%s\n", prog, ldirname,
> + err_string_ext);
> + empty_map = 1;
> + } else if (rc < 0) {
> + ret = 1;
> + } else {
> + empty_map = 1;
> + }
> +err_close_eventsfp:
>   fclose(eventsfp);
> - create_empty_mapping(output_file);
> + if (empty_map)
> + create_empty_mapping(output_file);
> +err_out:
>   free_arch_std_events();
> -out_free_mapfile:
>   free(mapfile);
>   return ret;
>  }
> 


Re: [PATCH 1/2] perf jevents: Tidy error handling

2020-10-21 Thread kajoljain



On 10/20/20 2:05 PM, John Garry wrote:
> On 20/10/2020 09:14, kajoljain wrote:
>>
>>
>> On 10/20/20 11:13 AM, Namhyung Kim wrote:
>>> Hello,
>>>
>>> On Tue, Oct 20, 2020 at 12:42 AM John Garry  wrote:
>>>>
>>>> There is much duplication in the error handling for directory traversing
>>>> for processing JSONs.
>>>>
>>>> Factor out the common code to tidy a bit.
>>>>
>>>> Signed-off-by: John Garry 
>>>> ---
>>> [SNIP]
>>>> -empty_map:
>>>> +err_processing_std_arch_event_dir:
>>>> +   err_string_ext = " for std arch event";
>>>> +err_processing_dir:
>>>> +   if (verbose || rc > 0) {
>>>> +   pr_info("%s: Error walking file tree %s%s\n", prog, 
>>>> ldirname,
>>>> +   err_string_ext);
>>>
>>> This was printed only if verbose is set but now changed.
>>
> 
> pr_info() is silenced if verbose is unset, so in effect it is the same - see 
> pr_info() definition in json.h
> 
>> Hi John,
>>     Yes I agree with Namhyung.
>> So, this is our original checks
>>
>> if (rc && verbose) {
>>     pr_info("%s: Error walking file tree %s\n", prog, ldirname);
>>     goto empty_map;
>> } else if (rc < 0) {
>>     /* Make build fail */
>>     fclose(eventsfp);
>>     free_arch_std_events();
>>     ret = 1;
>>     goto out_free_mapfile;
>> } else if (rc) {
>>     goto empty_map;
>> }
>>
>> May be we can use similar checks:
>>
>> if( verbose)
>>    pr_info("%s: Error walking file tree %s%s\n", prog, 
>> ldirname,err_string_ext);
>> if(rc > 0)
>>     empty_map = 1;
>> else
>>    ret = 1;
>>
> 
> Not that it matters much, this logic is slightly different for verbose set 
> and rc < 0. I don't mind going with that, so let me know.

Yes right. Sure if required we can made changes on these checks and include 
appropriate condition for verbose set and rc < 0. Seems fine to me.

Thanks,
Kajol Jain
> 
> Thanks for checking,
> John
> 
>> Thanks,
>> Kajol Jain
>>   
>>>
>>> Thanks
>>> Namhyung
>>>
>>>
>>>> +   empty_map = 1;
>>>> +   } else {
>>>> +   ret = 1;
>>>> +   }
>>>> +err_close_eventsfp:
>>>>  fclose(eventsfp);
>>>> -   create_empty_mapping(output_file);
>>>> +   if (empty_map)
>>>> +   create_empty_mapping(output_file);
>>>> +err_out:
>>>>  free_arch_std_events();
>>>> -out_free_mapfile:
>>>>  free(mapfile);
>>>>  return ret;
>>>>   }
>>>> -- 
>>>> 2.26.2
>>>>
>> .
>>
> 


Re: [perf metricgroup] fcc9c5243c: perf-sanity-tests.Parse_and_process_metrics.fail

2020-10-20 Thread kajoljain



On 10/19/20 9:50 PM, Ian Rogers wrote:
> On Mon, Oct 19, 2020 at 2:51 AM John Garry  wrote:
>>
>> On 19/10/2020 00:30, Ian Rogers wrote:
>>> On Sun, Oct 18, 2020 at 1:51 AM kernel test robot  
>>> wrote:

 Greeting,

 FYI, we noticed the following commit (built with gcc-9):

 commit: fcc9c5243c478f104014daf4d23db86098d2aef0 ("perf metricgroup: Hack 
 a fix for aliases when covering multiple PMUs")
 url: 
 https://github.com/0day-ci/linux/commits/John-Garry/perf-pmu-events-Support-event-aliasing-for-system-PMUs/20201008-182049


 in testcase: perf-sanity-tests
 version: perf-x86_64-c85fb28b6f99-1_20201008
 with following parameters:

  perf_compiler: gcc
  ucode: 0xdc



 on test machine: 4 threads Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz with 
 32G memory

 caused below changes (please refer to attached dmesg/kmsg for entire 
 log/backtrace):
>>>
>>> I believe this is a Skylake and there is a known bug in the Skylake
>>> metric DRAM_Parallel_Reads as described here:
>>> https://lore.kernel.org/lkml/CAP-5=fxejvaqa9qfw66cy77qb962+jbe8tt5bslooocfmod...@mail.gmail.com/
>>> Fixing the bug needs more knowledge than what is available in manuals.
>>> Hopefully Intel can take a look.
>>>
>>> Thanks,
>>> Ian
>>
>> So this named patch ("perf metricgroup: Hack a fix for aliases...") is
>> breaking test #67 on my machine also, which is a broadwell.
> 
> Thanks for taking a look John. If you want help you can send the
> output of "perf test 67 -vvv" to me. It is possible Broadwell has
> similar glitches in the json to Skylake. I tested the original test on
> server parts as I can access them as cloud machines.
> 
>> I will have a look, but I was hoping that Ian would have a proper fix
>> for this on top of ("perf metricgroup: Fix uncore metric expressions"),
>> which now looks to be merged.
> 
> I still have these changes to look at in my inbox but I'm assuming
> they're good :-) Sorry for not getting to them, but it's good they are
> merged.

Hi Ian,
   Checked in upstream kernel with your fix patch, in powerpc also test case 67 
is passing. 
But I am getting issue in test 10 for powerpc

[command]# ./perf test 10 
10: PMU events  :
10.1: PMU event table sanity: Ok
10.2: PMU event map aliases : Ok
10.3: Parsing of PMU event table metrics: Skip 
(some metrics failed)
10.4: Parsing of PMU event table metrics with fake PMUs : FAILED!

Was debugging it, issue is with commit e1c92a7fbbc5 perf tests: Add another 
metric parsing test.

So, there we are passing different runtime parameter value in "expr__find_other 
and expr__parse"
in function `metric_parse_fake`. I believe we need to send same value.
I will send fix patch for the same.

Thanks,
Kajol Jain

> 
> Thanks,
> Ian
> 
>> Thanks!
>>
>>>


 If you fix the issue, kindly add following tag
 Reported-by: kernel test robot 


 2020-10-16 19:31:52 sudo 
 /usr/src/perf_selftests-x86_64-rhel-8.3-fcc9c5243c478f104014daf4d23db86098d2aef0/tools/perf/perf
  test 67
 67: Parse and process metrics : FAILED!
 2020-10-16 19:31:52 sudo 
 /usr/src/perf_selftests-x86_64-rhel-8.3-fcc9c5243c478f104014daf4d23db86098d2aef0/tools/perf/perf
  test 68
 68: x86 rdpmc : Ok
 2020-10-16 19:31:52 sudo 
 /usr/src/perf_selftests-x86_64-rhel-8.3-fcc9c5243c478f104014daf4d23db86098d2aef0/tools/perf/perf
  test 69
 69: Convert perf time to TSC  : Ok
 2020-10-16 19:31:52 sudo 
 /usr/src/perf_selftests-x86_64-rhel-8.3-fcc9c5243c478f104014daf4d23db86098d2aef0/tools/perf/perf
  test 70
 70: DWARF unwind  : Ok
 2020-10-16 19:31:52 sudo 
 /usr/src/perf_selftests-x86_64-rhel-8.3-fcc9c5243c478f104014daf4d23db86098d2aef0/tools/perf/perf
  test 71
 71: x86 instruction decoder - new instructions: Ok
 2020-10-16 19:31:52 sudo 
 /usr/src/perf_selftests-x86_64-rhel-8.3-fcc9c5243c478f104014daf4d23db86098d2aef0/tools/perf/perf
  test 72
 72: Intel PT packet decoder   : Ok
 2020-10-16 19:31:52 sudo 
 /usr/src/perf_selftests-x86_64-rhel-8.3-fcc9c5243c478f104014daf4d23db86098d2aef0/tools/perf/perf
  test 73
 73: x86 bp modify : Ok
 2020-10-16 19:31:53 sudo 
 /usr/src/perf_selftests-x86_64-rhel-8.3-fcc9c5243c478f104014daf4d23db86098d2aef0/tools/perf/perf
  test 74
 74: probe libc's inet_pton & backtrace it with ping   : Ok
 2020-10-16 19:31:54 sudo 
 /usr/src/perf_selftests-x86_64-rhel-8.3-fcc9c5243c478f104014daf4d23db86098d2aef0/tools/perf/perf
  test 75

Re: [PATCH 1/2] perf jevents: Tidy error handling

2020-10-20 Thread kajoljain



On 10/20/20 11:13 AM, Namhyung Kim wrote:
> Hello,
> 
> On Tue, Oct 20, 2020 at 12:42 AM John Garry  wrote:
>>
>> There is much duplication in the error handling for directory traversing
>> for processing JSONs.
>>
>> Factor out the common code to tidy a bit.
>>
>> Signed-off-by: John Garry 
>> ---
> [SNIP]
>> -empty_map:
>> +err_processing_std_arch_event_dir:
>> +   err_string_ext = " for std arch event";
>> +err_processing_dir:
>> +   if (verbose || rc > 0) {
>> +   pr_info("%s: Error walking file tree %s%s\n", prog, ldirname,
>> +   err_string_ext);
> 
> This was printed only if verbose is set but now changed.

Hi John,
   Yes I agree with Namhyung.
So, this is our original checks

if (rc && verbose) {
pr_info("%s: Error walking file tree %s\n", prog, ldirname);
goto empty_map;
} else if (rc < 0) {
/* Make build fail */
fclose(eventsfp);
free_arch_std_events();
ret = 1;
goto out_free_mapfile;
} else if (rc) {
goto empty_map;
}

May be we can use similar checks:

if( verbose)
  pr_info("%s: Error walking file tree %s%s\n", prog, ldirname,err_string_ext);
if(rc > 0)
   empty_map = 1;
else
  ret = 1;

Thanks,
Kajol Jain
  
> 
> Thanks
> Namhyung
> 
> 
>> +   empty_map = 1;
>> +   } else {
>> +   ret = 1;
>> +   }
>> +err_close_eventsfp:
>> fclose(eventsfp);
>> -   create_empty_mapping(output_file);
>> +   if (empty_map)
>> +   create_empty_mapping(output_file);
>> +err_out:
>> free_arch_std_events();
>> -out_free_mapfile:
>> free(mapfile);
>> return ret;
>>  }
>> --
>> 2.26.2
>>


Re: [PATCH] perf vendor events: Fix typos in power8 PMU events

2020-10-12 Thread kajoljain



On 10/12/20 10:32 AM, Sandipan Das wrote:
> This replaces the incorrectly spelled word "localtion"
> with "location" in some power8 PMU event descriptions.

Patch looks good to me, Thanks for correcting it.

Reviewed-By: Kajol Jain

Thanks,
Kajol Jain
> 
> Fixes: 2a81fa3bb5ed ("perf vendor events: Add power8 PMU events")
> Signed-off-by: Sandipan Das 
> ---
>  .../pmu-events/arch/powerpc/power8/cache.json| 10 +-
>  .../pmu-events/arch/powerpc/power8/frontend.json | 12 ++--
>  .../pmu-events/arch/powerpc/power8/marked.json   | 10 +-
>  .../pmu-events/arch/powerpc/power8/other.json| 16 
>  .../arch/powerpc/power8/translation.json |  2 +-
>  5 files changed, 25 insertions(+), 25 deletions(-)
> 
> diff --git a/tools/perf/pmu-events/arch/powerpc/power8/cache.json 
> b/tools/perf/pmu-events/arch/powerpc/power8/cache.json
> index 6b792b2c87e2..05a17084d939 100644
> --- a/tools/perf/pmu-events/arch/powerpc/power8/cache.json
> +++ b/tools/perf/pmu-events/arch/powerpc/power8/cache.json
> @@ -32,8 +32,8 @@
>{
>  "EventCode": "0x1c04e",
>  "EventName": "PM_DATA_FROM_L2MISS_MOD",
> -"BriefDescription": "The processor's data cache was reloaded from a 
> localtion other than the local core's L2 due to a demand load",
> -"PublicDescription": "The processor's data cache was reloaded from a 
> localtion other than the local core's L2 due to either only demand loads or 
> demand loads plus prefetches if MMCR1[16] is 1"
> +"BriefDescription": "The processor's data cache was reloaded from a 
> location other than the local core's L2 due to a demand load",
> +"PublicDescription": "The processor's data cache was reloaded from a 
> location other than the local core's L2 due to either only demand loads or 
> demand loads plus prefetches if MMCR1[16] is 1"
>},
>{
>  "EventCode": "0x3c040",
> @@ -74,8 +74,8 @@
>{
>  "EventCode": "0x4c04e",
>  "EventName": "PM_DATA_FROM_L3MISS_MOD",
> -"BriefDescription": "The processor's data cache was reloaded from a 
> localtion other than the local core's L3 due to a demand load",
> -"PublicDescription": "The processor's data cache was reloaded from a 
> localtion other than the local core's L3 due to either only demand loads or 
> demand loads plus prefetches if MMCR1[16] is 1"
> +"BriefDescription": "The processor's data cache was reloaded from a 
> location other than the local core's L3 due to a demand load",
> +"PublicDescription": "The processor's data cache was reloaded from a 
> location other than the local core's L3 due to either only demand loads or 
> demand loads plus prefetches if MMCR1[16] is 1"
>},
>{
>  "EventCode": "0x3c042",
> @@ -134,7 +134,7 @@
>{
>  "EventCode": "0x4e04e",
>  "EventName": "PM_DPTEG_FROM_L3MISS",
> -"BriefDescription": "A Page Table Entry was loaded into the TLB from a 
> localtion other than the local core's L3 due to a data side request",
> +"BriefDescription": "A Page Table Entry was loaded into the TLB from a 
> location other than the local core's L3 due to a data side request",
>  "PublicDescription": ""
>},
>{
> diff --git a/tools/perf/pmu-events/arch/powerpc/power8/frontend.json 
> b/tools/perf/pmu-events/arch/powerpc/power8/frontend.json
> index 1ddc30655d43..1c902a8263b6 100644
> --- a/tools/perf/pmu-events/arch/powerpc/power8/frontend.json
> +++ b/tools/perf/pmu-events/arch/powerpc/power8/frontend.json
> @@ -116,8 +116,8 @@
>{
>  "EventCode": "0x1404e",
>  "EventName": "PM_INST_FROM_L2MISS",
> -"BriefDescription": "The processor's Instruction cache was reloaded from 
> a localtion other than the local core's L2 due to an instruction fetch (not 
> prefetch)",
> -"PublicDescription": "The processor's Instruction cache was reloaded 
> from a localtion other than the local core's L2 due to either an instruction 
> fetch or instruction fetch plus prefetch if MMCR1[17] is 1"
> +"BriefDescription": "The processor's Instruction cache was reloaded from 
> a location other than the local core's L2 due to an instruction fetch (not 
> prefetch)",
> +"PublicDescription": "The processor's Instruction cache was reloaded 
> from a location other than the local core's L2 due to either an instruction 
> fetch or instruction fetch plus prefetch if MMCR1[17] is 1"
>},
>{
>  "EventCode": "0x34040",
> @@ -158,8 +158,8 @@
>{
>  "EventCode": "0x4404e",
>  "EventName": "PM_INST_FROM_L3MISS_MOD",
> -"BriefDescription": "The processor's Instruction cache was reloaded from 
> a localtion other than the local core's L3 due to a instruction fetch",
> -"PublicDescription": "The processor's Instruction cache was reloaded 
> from a localtion other than the local core's L3 due to either an instruction 
> fetch or instruction fetch plus prefetch if MMCR1[17] is 1"
> +"BriefDescription": "The processor's Instruction cache was reloaded from 
> a 

Re: [PATCH] perf jevents: Fix event code for events referencing std arch events

2020-10-09 Thread kajoljain



On 10/8/20 8:49 PM, John Garry wrote:
> The event code for events referencing std arch events is incorrectly
> evaluated in json_events().
> 
> The issue is that je.event is evaluated properly from try_fixup(), but
> later NULLified from the real_event() call, as "event" may be NULL.
> 
> Fix by setting "event" same je.event in try_fixup().
> 
> Also remove support for overwriting event code for events using std arch
> events, as it is not used.

Patch looks good to me. Not sure if any adding any example with this issue
is helpful.

Reviewed-By: Kajol Jain

Thanks,
Kajol Jain
> 
> Signed-off-by: John Garry 
> 
> diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
> index 99df41a9543d..e47644cab3fa 100644
> --- a/tools/perf/pmu-events/jevents.c
> +++ b/tools/perf/pmu-events/jevents.c
> @@ -505,20 +505,15 @@ static char *real_event(const char *name, char *event)
>  }
>  
>  static int
> -try_fixup(const char *fn, char *arch_std, unsigned long long eventcode,
> -   struct json_event *je)
> +try_fixup(const char *fn, char *arch_std, struct json_event *je, char 
> **event)
>  {
>   /* try to find matching event from arch standard values */
>   struct event_struct *es;
>  
>   list_for_each_entry(es, _std_events, list) {
>   if (!strcmp(arch_std, es->name)) {
> - if (!eventcode && es->event) {
> - /* allow EventCode to be overridden */
> - free(je->event);
> - je->event = NULL;
> - }
>   FOR_ALL_EVENT_STRUCT_FIELDS(TRY_FIXUP_FIELD);
> + *event = je->event;
>   return 0;
>   }
>   }
> @@ -678,7 +673,7 @@ static int json_events(const char *fn,
>* An arch standard event is referenced, so try to
>* fixup any unassigned values.
>*/
> - err = try_fixup(fn, arch_std, eventcode, );
> + err = try_fixup(fn, arch_std, , );
>   if (err)
>   goto free_strings;
>   }
> 


Re: [PATCH] perf/core: Fix hung issue on perf stat command during cpu hotplug

2020-10-08 Thread kajoljain



On 8/27/20 12:17 PM, Kajol Jain wrote:
> Commit 2ed6edd33a21 ("perf: Add cond_resched() to task_function_call()")
> added assignment of ret value as -EAGAIN in case function
> call to 'smp_call_function_single' fails.
> For non-zero ret value, it did
> 'ret = !ret ? data.ret : -EAGAIN;', which always
> assign -EAGAIN to ret and make second if condition useless.
> 
> In scenarios like when executing a perf stat with --per-thread option, and
> if any of the monitoring cpu goes offline, the 'smp_call_function_single'
> function could return -ENXIO, and with the above check,
> task_function_call hung and increases CPU
> usage (because of repeated 'smp_call_function_single()')
> 
> Recration scenario:
>   # perf stat -a --per-thread && (offline a CPU )
> 
> Patch here removes the tertiary condition added as part of that
> commit and added a check for NULL and -EAGAIN.

Hi Peter,
 Please let me know if you have any comment on this patch.

Thanks,
Kajol Jain
> 
> Fixes: 2ed6edd33a21("perf: Add cond_resched() to task_function_call()")
> Signed-off-by: Kajol Jain 
> Reported-by: Srikar Dronamraju 
> Reviewed-by: Barret Rhoden 
> Tested-by: Srikar Dronamraju 
> ---
>  kernel/events/core.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> Changelog:
> - Remove RFC tag
> - Resolve some nits issues like space after if and
>   added -ENXIO in comment msg of function 'task_function_call'
>   as suggested by Barret Rhoden.
> 
> Link to the RFC: https://lkml.org/lkml/2020/8/26/896
> 
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 5bfe8e3c6e44..cef646084198 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -99,7 +99,7 @@ static void remote_function(void *data)
>   * retry due to any failures in smp_call_function_single(), such as if the
>   * task_cpu() goes offline concurrently.
>   *
> - * returns @func return value or -ESRCH when the process isn't running
> + * returns @func return value or -ESRCH or -ENXIO when the process isn't 
> running
>   */
>  static int
>  task_function_call(struct task_struct *p, remote_function_f func, void *info)
> @@ -115,7 +115,8 @@ task_function_call(struct task_struct *p, 
> remote_function_f func, void *info)
>   for (;;) {
>   ret = smp_call_function_single(task_cpu(p), remote_function,
>  , 1);
> - ret = !ret ? data.ret : -EAGAIN;
> + if (!ret)
> + ret = data.ret;
>  
>   if (ret != -EAGAIN)
>   break;
> 


Re: [PATCH RFC v4 00/13] perf pmu-events: Support event aliasing for system PMUs

2020-10-08 Thread kajoljain



On 10/8/20 3:45 PM, John Garry wrote:
> Currently event aliasing and metrics for only CPU and uncore PMUs is
> supported. In fact, only uncore PMUs aliasing is supported for when the
> uncore PMUs are fixed for a CPU, which may not always be the case for
> certain architectures.
> 
> This series adds support for PMU event aliasing and metrics for system and
> other uncore PMUs which are not tied to a specific CPU.
> 
> For this, we introduce system event tables in generated pmu-events.c,
> which contain a per-SoC table of events of all its system PMUs. Each
> per-PMU event is matched by a "COMPAT" property.
> 
> When creating aliased and metrics PMUs, we treat core/uncore and
> system PMUs differently:
> 
> - For CPU PMUs, we always match for the event mapfile based on the CPUID.
>   This has not changed.
> 
> - For an system PMUs, we iterate through all the events in all the system
>   PMU tables.
> 
>   Matches are based on the "COMPAT" property matching the PMU sysfs
>   identifier contents, in /sys/bus/event_source/devices//identifier
> 
>   Uncore PMUs, may be matched via CPUID or same as system PMU, depending
>   on whether the uncore PMU is tied to a specific CPUID.
> 
> Initial reference support is also added for ARM SMMUv3 PMCG (Performance
> Monitor Event Group) PMU for HiSilicon hip09 platform with only a single
> event so far - see driver in drivers/perf/arm_smmuv3_pmu.c reference.
> 
> Here is a sample output with this series on Huawei D06CS board:
> 
> root@ubuntu:/# ./perf list
>[...]
> 
> smmu v3 pmcg:
>smmuv3_pmcg.config_cache_miss
> [Configuration cache miss caused by transaction or(ATS or
> non-ATS)translation request. Unit: smmuv3_pmcg]
>smmuv3_pmcg.config_struct_access
> [Configuration structure access. Unit: smmuv3_pmcg]
>smmuv3_pmcg.cycles
> [Clock cycles. Unit: smmuv3_pmcg]
>smmuv3_pmcg.l1_tlb
> [SMMUv3 PMCG L1 TABLE transation. Unit: smmuv3_pmcg]
>smmuv3_pmcg.pcie_ats_trans_passed
> [PCIe ATS Translated Transaction passed through SMMU. Unit: 
> smmuv3_pmcg]
>smmuv3_pmcg.pcie_ats_trans_rq
> [PCIe ATS Translation Request received. Unit: smmuv3_pmcg]
>smmuv3_pmcg.tlb_miss
> [TLB miss caused by incomingtransaction or (ATS or non-ATS) 
> translation request. Unit: smmuv3_pmcg]
>smmuv3_pmcg.trans_table_walk_access
> [Translation table walk access. Unit: smmuv3_pmcg]
>smmuv3_pmcg.transaction
> [Transaction. Unit: smmuv3_pmcg]
> 
> 
> root@ubuntu:/# ./perf stat -v -e smmuv3_pmcg.l1_tlb sleep 1
> Using CPUID 0x480fd010
> Using SYSID HIP08
> -> smmuv3_pmcg_200100020/event=0x8a/
> -> smmuv3_pmcg_200140020/event=0x8a/
> -> smmuv3_pmcg_100020/event=0x8a/
> -> smmuv3_pmcg_140020/event=0x8a/
> -> smmuv3_pmcg_200148020/event=0x8a/
> -> smmuv3_pmcg_148020/event=0x8a/
> smmuv3_pmcg.l1_tlb: 0 1001221690 1001221690
> smmuv3_pmcg.l1_tlb: 0 1001220090 1001220090
> smmuv3_pmcg.l1_tlb: 101 1001219660 1001219660
> smmuv3_pmcg.l1_tlb: 0 1001219010 1001219010
> smmuv3_pmcg.l1_tlb: 0 1001218360 1001218360
> smmuv3_pmcg.l1_tlb: 134 1001217850 1001217850
> 
> Performance counter stats for 'system wide':
> 
> 235  smmuv3_pmcg.l1_tlb 
> 
> 1.001263128 seconds time elapsed
> 
> root@ubuntu:/#
> 
> Support is also added for imx8mm DDR PMU and HiSilicon hip09 uncore events.
> Some events for hip09 may not be accurate at the moment.
> 
> Series is here:
> https://github.com/hisilicon/kernel-dev/tree/private-topic-perf-5.9-sys-pmu-events-v4
> 
> Kernel part is here:
> https://lore.kernel.org/lkml/1602149181-237415-1-git-send-email-john.ga...@huawei.com/T/#mc34f758ab72f3d4a90d854b9bda7e6bbb90835b2
> 
> Differences to v3:
> - Rebase to v5.9-rc7
> - Includes Ian's uncore metric expressions Fix and another fix
> - Add hip09 uncore events
> - Tidy jevents.c changes a bit
> 
> Differences to v2:
> - fixups for imx8mm JSONs
> - fix for metrics being repeated per PMU
> - use sysfs__read_str()
> - fix typo in PMCG JSON
> - drop evsel fix, which someone else fixed
> 
> Differences to v1:
> - Stop using SoC id and use a per-PMU identifier instead
> - Add metric group sys events support
>- This is a bit hacky
> - Add imx8mm DDR Perf support
> - Add fix for parse events sel
>   - without it, I get this spewed for metric event:
> 
>   assertion failed at util/parse-events.c:1637
> 
> Ian Rogers (1):
>   perf metricgroup: Fix uncore metric expressions
> 
> Joakim Zhang (1):
>   perf vendor events: Add JSON metrics for imx8mm DDR Perf
> 
> John Garry (11):
>   perf jevents: Add support for an extra directory level
>   perf jevents: Add support for system events tables
>   perf pmu: Add pmu_id()
>   perf pmu: Add pmu_add_sys_aliases()
>   perf vendor events arm64: Add Architected events smmuv3-pmcg.json
>   perf vendor events arm64: Add hip09 SMMUv3 PMCG events
>   perf vendor events arm64: Add hip09 uncore events
>   perf metricgroup: Hack a fix for aliases when 

Re: [PATCH v8 3/5] perf jevents: Add support for parsing perchip/percore events

2020-09-07 Thread kajoljain



On 9/6/20 6:25 PM, Jiri Olsa wrote:
> On Sun, Sep 06, 2020 at 04:50:02PM +0530, Kajol Jain wrote:
> 
> SNIP
> 
>>  typedef int (*func)(void *data, struct json_event *je);
>>  
>>  int eprintf(int level, int var, const char *fmt, ...)
>> @@ -355,6 +368,8 @@ static int print_events_table_entry(void *data, struct 
>> json_event *je)
>>  fprintf(outfp, "\t.unit = \"%s\",\n", je->unit);
>>  if (je->perpkg)
>>  fprintf(outfp, "\t.perpkg = \"%s\",\n", je->perpkg);
>> +if (je->aggr_mode)
>> +fprintf(outfp, "\t.aggr_mode = \"%d\",\n", 
>> convert(je->aggr_mode));
>>  if (je->metric_expr)
>>  fprintf(outfp, "\t.metric_expr = \"%s\",\n", je->metric_expr);
>>  if (je->metric_name)
>> @@ -379,6 +394,7 @@ struct event_struct {
>>  char *pmu;
>>  char *unit;
>>  char *perpkg;
>> +char *aggr_mode;
>>  char *metric_expr;
>>  char *metric_name;
>>  char *metric_group;
>> @@ -408,6 +424,7 @@ struct event_struct {
>>  op(pmu);\
>>  op(unit);   \
>>  op(perpkg); \
>> +op(aggr_mode);  \
>>  op(metric_expr);\
>>  op(metric_name);\
>>  op(metric_group);   \
>> @@ -613,6 +630,8 @@ static int json_events(const char *fn,
>>  addfield(map, , "", "", val);
>>  } else if (json_streq(map, field, "PerPkg")) {
>>  addfield(map, , "", "", val);
>> +} else if (json_streq(map, field, "AggregationMode")) {
>> +addfield(map, _mode, "", "", val);
> 
> I think you should free je.aggr_mode

My bad, missed that part. Will send updated one.

Thanks,
Kajol Jain
> 
> jirka
> 
>>  } else if (json_streq(map, field, "Deprecated")) {
>>  addfield(map, , "", "", val);
>>  } else if (json_streq(map, field, "MetricName")) {
>> diff --git a/tools/perf/pmu-events/pmu-events.h 
>> b/tools/perf/pmu-events/pmu-events.h
>> index c8f306b572f4..7da1a3743b77 100644
>> --- a/tools/perf/pmu-events/pmu-events.h
>> +++ b/tools/perf/pmu-events/pmu-events.h
>> @@ -2,6 +2,11 @@
>>  #ifndef PMU_EVENTS_H
>>  #define PMU_EVENTS_H
>>  
>> +enum aggr_mode_class {
>> +PerChip = 1,
>> +PerCore
>> +};
>> +
>>  /*
>>   * Describe each PMU event. Each CPU has a table of PMU events.
>>   */
>> @@ -14,6 +19,7 @@ struct pmu_event {
>>  const char *pmu;
>>  const char *unit;
>>  const char *perpkg;
>> +const char *aggr_mode;
>>  const char *metric_expr;
>>  const char *metric_name;
>>  const char *metric_group;
>> -- 
>> 2.26.2
>>
> 


Re: [PATCH v7 2/5] perf/jevents: Add new structure to pass json fields.

2020-09-04 Thread kajoljain



On 9/3/20 8:24 PM, Namhyung Kim wrote:
> Hello,
> 
> On Thu, Sep 3, 2020 at 1:05 AM Kajol Jain  wrote:
>>
>> This patch adds new structure called 'json_event' inside jevents.h
> 
> jevents.c ?

Hi Namhyung,
   Right, I will update it.

Thanks,
Kajol Jain
> 
> Thanks
> Namhyung
> 
>> file to improve the callback prototype inside jevent files.
>> Initially, whenever user want to add new field, they need to update
>> in all function callback which make it more and more complex with
>> increased number of parmeters.
>> With this change, we just need to add it in new structure 'json_event'.
>>
>> Signed-off-by: Kajol Jain 
>> Reviewed-by: Andi Kleen 


Re: [PATCH v7 2/5] perf/jevents: Add new structure to pass json fields.

2020-09-04 Thread kajoljain



On 9/2/20 10:35 PM, John Garry wrote:
> On 02/09/2020 17:04, Kajol Jain wrote:
>> This patch adds new structure called 'json_event' inside jevents.h
>> file to improve the callback prototype inside jevent files.
>> Initially, whenever user want to add new field, they need to update
>> in all function callback which make it more and more complex with
>> increased number of parmeters.
>> With this change, we just need to add it in new structure 'json_event'.
>>
>> Signed-off-by: Kajol Jain 
>> Reviewed-by: Andi Kleen 
> 
> Reviewed-by: John Garry 
> 
>> +static int json_events
> 
> Adding 'static' should have really been in the previous patch ...

Hi John,
   Right, Thanks for pointing it, I will update.

Thanks,
Kajol Jain
> 


Re: [PATCH] perf/core: Fix hung issue on perf stat command during cpu hotplug

2020-09-02 Thread kajoljain



On 9/2/20 8:35 PM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Aug 27, 2020 at 12:17:32PM +0530, Kajol Jain escreveu:
>> Commit 2ed6edd33a21 ("perf: Add cond_resched() to task_function_call()")
>> added assignment of ret value as -EAGAIN in case function
>> call to 'smp_call_function_single' fails.
>> For non-zero ret value, it did
>> 'ret = !ret ? data.ret : -EAGAIN;', which always
>> assign -EAGAIN to ret and make second if condition useless.
>>
>> In scenarios like when executing a perf stat with --per-thread option, and
>> if any of the monitoring cpu goes offline, the 'smp_call_function_single'
>> function could return -ENXIO, and with the above check,
>> task_function_call hung and increases CPU
>> usage (because of repeated 'smp_call_function_single()')
>>
>> Recration scenario:
>>  # perf stat -a --per-thread && (offline a CPU )
>>
>> Patch here removes the tertiary condition added as part of that
>> commit and added a check for NULL and -EAGAIN.
> 
> I reproduced this issue with v5.9-rc3, now have to reboot for a conf
> call, will try to test the patch afterwards,
> 
> [65108.467416] IRQ 165: no longer affine to CPU23
> [65108.468495] smpboot: CPU 23 is now offline
> [65129.003879] Uhhuh. NMI received for unknown reason 1c on CPU 20.
> [65129.003880] Do you have a strange power saving mode enabled?
> [65129.003880] Dazed and confused, but trying to continue
> [65156.155539] Uhhuh. NMI received for unknown reason 1c on CPU 2.
> [65156.155539] Do you have a strange power saving mode enabled?
> [65156.155540] Dazed and confused, but trying to continue
> [65161.985284] Uhhuh. NMI received for unknown reason 1c on CPU 21.
> [65161.985285] Do you have a strange power saving mode enabled?
> [65161.985285] Dazed and confused, but trying to continue
> [65183.15] Uhhuh. NMI received for unknown reason 1c on CPU 1.
> [65183.154445] Do you have a strange power saving mode enabled?
> [65183.154446] Dazed and confused, but trying to continue
> [65189.724797] Uhhuh. NMI received for unknown reason 0c on CPU 4.
> [65189.724798] Do you have a strange power saving mode enabled?
> [65189.724799] Dazed and confused, but trying to continue
> [65196.259918] Uhhuh. NMI received for unknown reason 1c on CPU 11.
> [65196.259918] Do you have a strange power saving mode enabled?
> [65196.259918] Dazed and confused, but trying to continue
> [65234.794490] Uhhuh. NMI received for unknown reason 0c on CPU 5.
> [65234.794491] Do you have a strange power saving mode enabled?
> [65234.794491] Dazed and confused, but trying to continue
> [65454.559831] Uhhuh. NMI received for unknown reason 1c on CPU 19.
> [65454.559832] Do you have a strange power saving mode enabled?
> [65454.559832] Dazed and confused, but trying to continue
> [65529.657789] Uhhuh. NMI received for unknown reason 1c on CPU 3.
> [65529.657790] Do you have a strange power saving mode enabled?
> [65529.657790] Dazed and confused, but trying to continue
> [acme@five perf]$
> 
> 
> Things seems to be working again after bringing that CPU back online:

Hi Arnaldo,
You are right, once we bring back the CPU again, things will start working 
as our 'smp_call_function_single'
will not fail and we will come out of the loop. But till then, 
task_function_call will be hung.

Thanks,
Kajol Jain
> 
> [root@five ~]# perf top --stdio -C 0-22
> Error:
> The sys_perf_event_open() syscall returned with 16 (Device or resource busy) 
> for event (cycles).
> /bin/dmesg | grep -i perf may provide additional information.
> 
> [root@five ~]# perf stat -e cycles sleep 1
> Error:
> The sys_perf_event_open() syscall returned with 16 (Device or resource busy) 
> for event (cycles).
> /bin/dmesg | grep -i perf may provide additional information.
> 
> [root@five ~]# perf record -e cycles sleep 1
> Error:
> The sys_perf_event_open() syscall returned with 16 (Device or resource busy) 
> for event (cycles).
> /bin/dmesg | grep -i perf may provide additional information.
> 
> [root@five ~]# echo 1 > /sys/devices/system/cpu/cpu23/online
> [root@five ~]# perf record -e cycles sleep 1
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.039 MB perf.data (7 samples) ]
> [root@five ~]# perf stat -e cycles sleep 1
> 
>  Performance counter stats for 'sleep 1':
> 
>842,743  cycles
> 
>1.000903853 seconds time elapsed
> 
>0.000902000 seconds user
>0.0 seconds sys
> 
> 
> [root@five ~]# perf stat -e cycles sleep 1
> 
> 
> - Arnaldo
> 
>  
>> Fixes: 2ed6edd33a21("perf: Add cond_resched() to task_function_call()")
>> Signed-off-by: Kajol Jain 
>> Reported-by: Srikar Dronamraju 
>> Reviewed-by: Barret Rhoden 
>> Tested-by: Srikar Dronamraju 
>> ---
>>  kernel/events/core.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> Changelog:
>> - Remove RFC tag
>> - Resolve some nits issues like space after if and
>>   added -ENXIO in comment msg of function 'task_function_call'
>>   as suggested by 

Re: [PATCH v6 3/5] perf jevents: Add support for parsing perchip/percore events

2020-09-01 Thread kajoljain



On 8/31/20 2:14 PM, Jiri Olsa wrote:
> On Thu, Aug 27, 2020 at 06:39:56PM +0530, Kajol Jain wrote:
>> Initially, every time we want to add new terms like chip, core thread etc,
>> we need to create corrsponding fields in pmu_events and event struct.
>> This patch adds an enum called 'aggr_mode_class' which store all these
>> aggregation like perchip/percore. It also adds new field 'aggr_mode'
>> to capture these terms.
>> Now, if user wants to add any new term, they just need to add it in
>> the enum defined.
>>
>> Signed-off-by: Kajol Jain 
>> ---
>>  tools/perf/pmu-events/jevents.c| 16 
>>  tools/perf/pmu-events/pmu-events.h |  6 ++
>>  2 files changed, 22 insertions(+)
>>
>> diff --git a/tools/perf/pmu-events/jevents.c 
>> b/tools/perf/pmu-events/jevents.c
>> index b205cd904a4f..f4ad2d403533 100644
>> --- a/tools/perf/pmu-events/jevents.c
>> +++ b/tools/perf/pmu-events/jevents.c
>> @@ -48,6 +48,7 @@
>>  #include 
>>  #include "jsmn.h"
>>  #include "json.h"
>> +#include "pmu-events.h"
>>  
>>  int verbose;
>>  char *prog;
>> @@ -60,6 +61,7 @@ struct json_event {
>>  char *pmu;
>>  char *unit;
>>  char *perpkg;
>> +char *aggr_mode;
>>  char *metric_expr;
>>  char *metric_name;
>>  char *metric_group;
>> @@ -74,6 +76,14 @@ struct json_event {
>>  (void)(&_min1 == &_min2);   \
>>  _min1 < _min2 ? _min1 : _min2; })
>>  #endif
> 
> please add new line in here
> 

yes, will add.

>> +enum aggr_mode_class convert(const char *aggr_mode)
>> +{
>> +if (!strcmp(aggr_mode, "PerCore"))
>> +return PerCore;
>> +else if (!strcmp(aggr_mode, "PerChip"))
>> +return PerChip;
>> +return -1;
> 
> should we display some warning in here?

Sure can do that.

Thanks,
Kajol Jain
> 
> thanks,
> jirka
> 


Re: [PATCH v6 2/5] perf/jevents: Add new structure to pass json fields.

2020-09-01 Thread kajoljain



On 8/31/20 2:13 PM, Jiri Olsa wrote:
> On Thu, Aug 27, 2020 at 06:39:55PM +0530, Kajol Jain wrote:
> 
> SNIP
> 
>> -if (!*field)\
>> +#define TRY_FIXUP_FIELD(field) do { if (es->field && !je->field) {\
>> +je->field = strdup(es->field);  \
>> +if (!je->field) \
>>  return -ENOMEM; \
>>  } } while (0)
>>  
>> @@ -428,11 +440,7 @@ static void free_arch_std_events(void)
>>  }
>>  }
>>  
>> -static int save_arch_std_events(void *data, char *name, char *event,
>> -char *desc, char *long_desc, char *pmu,
>> -char *unit, char *perpkg, char *metric_expr,
>> -char *metric_name, char *metric_group,
>> -char *deprecated, char *metric_constraint)
>> +static int save_arch_std_events(void *data, struct json_event *je)
>>  {
>>  struct event_struct *es;
>>  
>> @@ -486,17 +494,16 @@ static char *real_event(const char *name, char *event)
>>  return NULL;
>>  
>>  for (i = 0; fixed[i].name; i++)
>> -if (!strcasecmp(name, fixed[i].name))
>> -return (char *)fixed[i].event;
>> +if (!strcasecmp(name, fixed[i].name)) {
>> +strcpy(event, fixed[i].event);
> 
> hum what's this strcpy for in here? we're just replacing separated
> variables with struct members, why do you need to copy the event in
> here?
> 

Hi Jiri,
Actually, initially when events is not part of 'json_event' structure, we 
are not
assigning result of function `real_event` to event field. But as we are not 
passing
event filed separately in functions like 'save_arch_std_events', freeing event
memory was giving me issue as we are returning pointer from real_event function 
in some cases.
So, that's why I replace it to strcpy to make sure we free je.event memory. Or 
should I remove
free(je.event) part?

-   err = func(data, name, real_event(name, event), desc, long_desc,
-  pmu, unit, perpkg, metric_expr, metric_name,
-  metric_group, deprecated, metric_constraint);
+   je.event = real_event(je.name, je.event);

This is the part, I am referring, here we are assigning result of real_event 
into je.event field.

Thanks,
Kajol Jain
> thanks,
> jirka
> 


Re: [PATCH v6 1/5] perf/jevents: Remove jevents.h file

2020-08-31 Thread kajoljain



On 8/31/20 2:31 PM, John Garry wrote:
> On 31/08/2020 09:43, Jiri Olsa wrote:
>> On Thu, Aug 27, 2020 at 06:39:54PM +0530, Kajol Jain wrote:
>>> This patch removes jevents.h file and add its data inside
>>> jevents.c as this file is only included there.
>>>
>>> Signed-off-by: Kajol Jain 
>>> ---
>>>   tools/perf/pmu-events/jevents.c |  9 -
>>>   tools/perf/pmu-events/jevents.h | 23 ---
>>>   2 files changed, 8 insertions(+), 24 deletions(-)
>>>   delete mode 100644 tools/perf/pmu-events/jevents.h
>>>
>>> diff --git a/tools/perf/pmu-events/jevents.c 
>>> b/tools/perf/pmu-events/jevents.c
>>> index fa86c5f997cc..1c55cc754b5a 100644
>>> --- a/tools/perf/pmu-events/jevents.c
>>> +++ b/tools/perf/pmu-events/jevents.c
>>> @@ -48,11 +48,18 @@
>>>   #include 
>>>   #include "jsmn.h"
>>>   #include "json.h"
>>> -#include "jevents.h"
>>>     int verbose;
>>>   char *prog;
>>>   +#ifndef min
>>> +#define min(x, y) ({    \
>>> +    typeof(x) _min1 = (x);    \
>>> +    typeof(y) _min2 = (y);    \
>>> +    (void)(&_min1 == &_min2);    \
>>> +    _min1 < _min2 ? _min1 : _min2; })
>>> +#endif
> 
> Wondering what is special about this definition of min that it's required? 
> Compiled ok for me without it.

Hi John,
 You are right, for me also in power it compiled without any issues, but 
not sure if somewhere we have dependency,
that's why I didn't remove it. 

Thanks,
Kajol Jain
> 
>>> +
>>>   int eprintf(int level, int var, const char *fmt, ...)
>>>   {
>>>   diff --git a/tools/perf/pmu-events/jevents.h 
>>> b/tools/perf/pmu-events/jevents.h
>>> deleted file mode 100644
>>> index 2afc8304529e..
>>> --- a/tools/perf/pmu-events/jevents.h
>>> +++ /dev/null
>>> @@ -1,23 +0,0 @@
>>> -/* SPDX-License-Identifier: GPL-2.0 */
>>> -#ifndef JEVENTS_H
>>> -#define JEVENTS_H 1
>>> -
>>> -int json_events(const char *fn,
>>> -    int (*func)(void *data, char *name, char *event, char *desc,
>>> -    char *long_desc,
>>> -    char *pmu,
>>> -    char *unit, char *perpkg, char *metric_expr,
>>> -    char *metric_name, char *metric_group,
>>> -    char *deprecated, char *metric_constraint),
>>> -    void *data);
>>> -char *get_cpu_str(void);
>>
>> I think you can also remove get_cpu_str from jevents.c
>>
>> thanks,
>> jirka
>>
>> .
>>
> 


Re: [PATCH v6 1/5] perf/jevents: Remove jevents.h file

2020-08-31 Thread kajoljain



On 8/31/20 2:13 PM, Jiri Olsa wrote:
> On Thu, Aug 27, 2020 at 06:39:54PM +0530, Kajol Jain wrote:
>> This patch removes jevents.h file and add its data inside
>> jevents.c as this file is only included there.
>>
>> Signed-off-by: Kajol Jain 
>> ---
>>  tools/perf/pmu-events/jevents.c |  9 -
>>  tools/perf/pmu-events/jevents.h | 23 ---
>>  2 files changed, 8 insertions(+), 24 deletions(-)
>>  delete mode 100644 tools/perf/pmu-events/jevents.h
>>
>> diff --git a/tools/perf/pmu-events/jevents.c 
>> b/tools/perf/pmu-events/jevents.c
>> index fa86c5f997cc..1c55cc754b5a 100644
>> --- a/tools/perf/pmu-events/jevents.c
>> +++ b/tools/perf/pmu-events/jevents.c
>> @@ -48,11 +48,18 @@
>>  #include 
>>  #include "jsmn.h"
>>  #include "json.h"
>> -#include "jevents.h"
>>  
>>  int verbose;
>>  char *prog;
>>  
>> +#ifndef min
>> +#define min(x, y) ({\
>> +typeof(x) _min1 = (x);  \
>> +typeof(y) _min2 = (y);  \
>> +(void)(&_min1 == &_min2);   \
>> +_min1 < _min2 ? _min1 : _min2; })
>> +#endif
>> +
>>  int eprintf(int level, int var, const char *fmt, ...)
>>  {
>>  
>> diff --git a/tools/perf/pmu-events/jevents.h 
>> b/tools/perf/pmu-events/jevents.h
>> deleted file mode 100644
>> index 2afc8304529e..
>> --- a/tools/perf/pmu-events/jevents.h
>> +++ /dev/null
>> @@ -1,23 +0,0 @@
>> -/* SPDX-License-Identifier: GPL-2.0 */
>> -#ifndef JEVENTS_H
>> -#define JEVENTS_H 1
>> -
>> -int json_events(const char *fn,
>> -int (*func)(void *data, char *name, char *event, char *desc,
>> -char *long_desc,
>> -char *pmu,
>> -char *unit, char *perpkg, char *metric_expr,
>> -char *metric_name, char *metric_group,
>> -char *deprecated, char *metric_constraint),
>> -void *data);
>> -char *get_cpu_str(void);
> 
> I think you can also remove get_cpu_str from jevents.c

Hi Jiri,
 Yes, I will check that part.

Thanks,
Kajol Jain
> 
> thanks,
> jirka
> 


Re: [perf/core] 16fb162e78: WARNING:at_kernel/events/core.c:#list_add_event

2020-08-27 Thread kajoljain



On 8/27/20 2:07 PM, kernel test robot wrote:
> Greeting,
> 
> FYI, we noticed the following commit (built with gcc-9):
> 
> commit: 16fb162e7868b8f3c1fc09ef0d683c9554cb6404 ("[RFC] perf/core: Fixes 
> hung issue on perf stat command during cpu hotplug")
> url: 
> https://github.com/0day-ci/linux/commits/Kajol-Jain/perf-core-Fixes-hung-issue-on-perf-stat-command-during-cpu-hotplug/20200826-173643
> base: https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git 
> 2cb5383b30d47c446ec7d884cd80f93ffcc31817
> 

Hi Rong Chen,
Thanks for checking. Actually this is old patch, I recently send new 
updated patch.
Please let me know if in this patch also you are seeing same issue.

Link to the patch: https://lkml.org/lkml/2020/8/27/101

Thanks,
Kajol Jain

> in testcase: trinity
> with following parameters:
> 
>   runtime: 300s
> 
> test-description: Trinity is a linux system call fuzz tester.
> test-url: http://codemonkey.org.uk/projects/trinity/
> 
> 
> on test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 8G
> 
> caused below changes (please refer to attached dmesg/kmsg for entire 
> log/backtrace):
> 
> 
> +-+++
> | | 2cb5383b30 | 16fb162e78 |
> +-+++
> | boot_successes  | 4  | 0  |
> | boot_failures   | 0  | 8  |
> | WARNING:at_kernel/events/core.c:#list_add_event | 0  | 8  |
> | EIP:list_add_event  | 0  | 8  |
> | kernel_BUG_at_lib/list_debug.c  | 0  | 8  |
> | invalid_opcode:#[##]| 0  | 8  |
> | EIP:__list_add_valid| 0  | 8  |
> | Kernel_panic-not_syncing:Fatal_exception| 0  | 8  |
> +-+++
> 
> 
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot 
> 
> 
> [   97.084211] WARNING: CPU: 0 PID: 593 at kernel/events/core.c:1807 
> list_add_event+0x29e/0x4b0
> [   97.086779] Modules linked in:
> [   97.087756] CPU: 0 PID: 593 Comm: trinity-main Not tainted 
> 5.9.0-rc1-00012-g16fb162e7868b #1
> [   97.089783] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.12.0-1 04/01/2014
> [   97.091980] EIP: list_add_event+0x29e/0x4b0
> [   97.093322] Code: ef c2 c4 01 83 15 44 ef c2 c4 00 8b 43 60 a8 01 0f 84 9a 
> fd ff ff 8d b6 00 00 00 00 83 05 48 ef c2 c4 01 83 15 4c ef c2 c4 00 <0f> 0b 
> 83 05 50 ef c2 c4 01 83 15 54 ef c2 c4 00 e9 71 fd ff ff 8d
> [   97.097789] EAX: 0007 EBX: eee48000 ECX: 0001 EDX: ee125280
> [   97.099297] ESI: eeebe200 EDI: 0001 EBP: eee67dfc ESP: eee67dec
> [   97.101008] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00010046
> [   97.106936] CR0: 80050033 CR2: 08dfc000 CR3: 2e0bb000 CR4: 00040690
> [   97.108599] Call Trace:
> [   97.109457]  __perf_install_in_context+0x286/0x3e0
> [   97.110759]  remote_function+0x79/0x90
> [   97.111897]  generic_exec_single+0xc3/0x190
> [   97.113101]  smp_call_function_single+0x1a3/0x2d0
> [   97.114364]  ? bpf_fd_reuseport_array_update_elem+0x300/0x300
> [   97.115866]  task_function_call+0x87/0xc0
> [   97.117025]  ? __perf_event_enable+0x740/0x740
> [   97.118248]  perf_install_in_context+0x110/0x450
> [   97.119540]  __do_sys_perf_event_open+0x13cb/0x1ed0
> [   97.120833]  __ia32_sys_perf_event_open+0x24/0x40
> [   97.122097]  __do_fast_syscall_32+0x99/0x110
> [   97.123213]  do_fast_syscall_32+0x37/0x130
> [   97.124409]  do_SYSENTER_32+0x23/0x40
> [   97.125470]  entry_SYSENTER_32+0xb0/0x10d
> [   97.126592] EIP: 0xb7f11549
> [   97.127449] Code: 03 74 c0 01 10 05 03 74 b8 01 10 06 03 74 b4 01 10 07 03 
> 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 
> 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00
> [   97.131832] EAX: ffda EBX: 08e38318 ECX:  EDX: 
> [   97.137556] ESI:  EDI: 0002 EBP: 6d656d83 ESP: bfa804ec
> [   97.139119] DS: 007b ES: 007b FS:  GS: 0033 SS: 007b EFLAGS: 0286
> [   97.140732] ---[ end trace 57d55e687e8b0e41 ]---
> 
> 
> To reproduce:
> 
> # build kernel
>   cd linux
>   cp config-5.9.0-rc1-00012-g16fb162e7868b .config
>   make HOSTCC=gcc-9 CC=gcc-9 ARCH=i386 olddefconfig prepare 
> modules_prepare bzImage
> 
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp qemu -k  job-script # job-script is attached in this 
> email
> 
> 
> 
> Thanks,
> Rong Chen
> 


Re: [RFC] perf/jevents: Add new structure to pass json fields.

2020-08-27 Thread kajoljain



On 8/26/20 5:29 PM, Jiri Olsa wrote:
> On Wed, Aug 26, 2020 at 05:02:04PM +0530, kajoljain wrote:
>>
>>
>> On 8/26/20 4:26 PM, Jiri Olsa wrote:
>>> On Tue, Aug 25, 2020 at 01:10:41PM +0530, Kajol Jain wrote:
>>>
>>> SNIP
>>>
>>>>  {
>>>>/* try to find matching event from arch standard values */
>>>>struct event_struct *es;
>>>> @@ -498,8 +486,7 @@ try_fixup(const char *fn, char *arch_std, char 
>>>> **event, char **desc,
>>>>if (!strcmp(arch_std, es->name)) {
>>>>if (!eventcode && es->event) {
>>>>/* allow EventCode to be overridden */
>>>> -  free(*event);
>>>> -  *event = NULL;
>>>> +  je->event = NULL;
>>>>}
>>>>FOR_ALL_EVENT_STRUCT_FIELDS(TRY_FIXUP_FIELD);
>>>>return 0;
>>>> @@ -513,13 +500,8 @@ try_fixup(const char *fn, char *arch_std, char 
>>>> **event, char **desc,
>>>>  
>>>>  /* Call func with each event in the json file */
>>>>  int json_events(const char *fn,
>>>> -int (*func)(void *data, char *name, char *event, char *desc,
>>>> -char *long_desc,
>>>> -char *pmu, char *unit, char *perpkg,
>>>> -char *metric_expr,
>>>> -char *metric_name, char *metric_group,
>>>> -char *deprecated, char *metric_constraint),
>>>> -void *data)
>>>> +  int (*func)(void *data, struct json_event *je),
>>>> +  void *data)
>>>>  {
>>>>int err;
>>>>size_t size;
>>>> @@ -537,24 +519,16 @@ int json_events(const char *fn,
>>>>EXPECT(tokens->type == JSMN_ARRAY, tokens, "expected top level array");
>>>>tok = tokens + 1;
>>>>for (i = 0; i < tokens->size; i++) {
>>>> -  char *event = NULL, *desc = NULL, *name = NULL;
>>>> -  char *long_desc = NULL;
>>>>char *extra_desc = NULL;
>>>> -  char *pmu = NULL;
>>>>char *filter = NULL;
>>>> -  char *perpkg = NULL;
>>>> -  char *unit = NULL;
>>>> -  char *metric_expr = NULL;
>>>> -  char *metric_name = NULL;
>>>> -  char *metric_group = NULL;
>>>> -  char *deprecated = NULL;
>>>> -  char *metric_constraint = NULL;
>>>> +  struct json_event *je;
>>>>char *arch_std = NULL;
>>>>unsigned long long eventcode = 0;
>>>>struct msrmap *msr = NULL;
>>>>jsmntok_t *msrval = NULL;
>>>>jsmntok_t *precise = NULL;
>>>>jsmntok_t *obj = tok++;
>>>> +  je = (struct json_event *)calloc(1, sizeof(struct json_event));
>>>
>>> hum, you don't check je pointer in here.. but does it need to be allocated?
>>> looks like you could just have je on stack as well..
>>
>> Hi Jiri,
>>Yes I will add check for je pointer here.The reason for allocating memory 
>> to 'je' is,
>> later we are actually referring one by one to its field and in case if won't 
>> allocate memory
>> we will get segmentaion fault as otherwise je will be NULL. Please let me 
>> know if I am
>> getting correct.
> 
> I don't see reason why not to use automatic variable in here,
> I tried and it seems to work.. below is diff to your changes,
> feel free to squash it with your changes

Hi Jiri,
Thanks for the changes, I will update.

Thanks,
Kajol Jain
> 
> jirka
> 
> ---
> diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
> index 606805af69fe..eaac5c126a52 100644
> --- a/tools/perf/pmu-events/jevents.c
> +++ b/tools/perf/pmu-events/jevents.c
> @@ -521,14 +521,13 @@ int json_events(const char *fn,
>   for (i = 0; i < tokens->size; i++) {
>   char *extra_desc = NULL;
>   char *filter = NULL;
> - struct json_event *je;
> + struct json_event je = {};
>   char *arch_std = NULL;
>   unsigned long long eventcode = 0;
>   struct msrmap *msr = NULL;
>   jsmntok_t *msrval = NULL;
>   jsmntok_t *precis

Re: [RFC] perf/jevents: Add new structure to pass json fields.

2020-08-27 Thread kajoljain



On 8/26/20 5:03 PM, John Garry wrote:
> On 26/08/2020 12:24, kajoljain wrote:
>>
>>
>> On 8/26/20 4:30 PM, Jiri Olsa wrote:
>>> On Tue, Aug 25, 2020 at 09:14:11AM +0100, John Garry wrote:
>>>
>>> SNIP
>>>
>>>>>    goto free_strings;
>>>>>    }
>>>>> -    err = func(data, name, real_event(name, event), desc, long_desc,
>>>>> -   pmu, unit, perpkg, metric_expr, metric_name,
>>>>> -   metric_group, deprecated, metric_constraint);
>>>>> +    je->event = real_event(je->name, je->event);
>>>>> +    err = func(data, je);
>>>>>    free_strings:
>>>>> -    free(event);
>>>>> -    free(desc);
>>>>> -    free(name);
>>>>> -    free(long_desc);
>>>>>    free(extra_desc);
>>>>> -    free(pmu);
>>>>>    free(filter);
>>>>> -    free(perpkg);
>>>>> -    free(deprecated);
>>>>> -    free(unit);
>>>>> -    free(metric_expr);
>>>>> -    free(metric_name);
>>>>> -    free(metric_group);
>>>>> -    free(metric_constraint);
> 
> Hi Kajol Jain,
> 
> Do we need to free je->metric_name and the rest still? From a glance, that 
> memory is still separately alloc'ed in addfield.

Hi John,
yes right we should free them as well. Thanks for pointing it, I will 
update.

Thanks,
Kajol Jain
> 
>>>>>    free(arch_std);
>>>>> +    free(je);
>>>>>    if (err)
>>>>>    break;
>>>>> diff --git a/tools/perf/pmu-events/jevents.h 
>>>>> b/tools/perf/pmu-events/jevents.h
>>>>> index 2afc8304529e..e696edf70e9a 100644
>>>>> --- a/tools/perf/pmu-events/jevents.h
>>>>> +++ b/tools/perf/pmu-events/jevents.h
>>>>
>>>> Somewhat unrelated - this file only seems to be included in jevents.c, so I
>>>> don't see why it exists...
>>>
>>> ah right.. I won't mind getting rid of it
>>
>> Hi John and  Jiri
>>   Thanks for reviewing the patch. I can remove this file and add these 
>> structure inside jevents.c
> 
> thanks
> 
>>
>> Thanks,
>> Kajol Jain
>>>  
>>>>> @@ -2,14 +2,28 @@
>>>>>    #ifndef JEVENTS_H
>>>>>    #define JEVENTS_H 1
>>>>> +#include "pmu-events.h"
>>>>> +
>>>>> +struct json_event {
>>>>> +    char *name;
>>>>> +    char *event;
>>>>> +    char *desc;
>>>>> +    char *topic;
>>>>> +    char *long_desc;
>>>>> +    char *pmu;
>>>>> +    char *unit;
>>>>> +    char *perpkg;
>>>>> +    char *metric_expr;
>>>>> +    char *metric_name;
>>>>> +    char *metric_group;
>>>>> +    char *deprecated;
>>>>> +    char *metric_constraint;
>>>>
>>>> This looks very much like struct event_struct, so could look to 
>>>> consolidate:
>>>>
>>>> struct event_struct {
>>>> struct list_head list;
>>>> char *name;
>>>> char *event;
>>>> char *desc;
>>>> char *long_desc;
>>>> char *pmu;
>>>> char *unit;
>>>> char *perpkg;
>>>> char *metric_expr;
>>>> char *metric_name;
>>>> char *metric_group;
>>>> char *deprecated;
>>>> char *metric_constraint;
>>>> };
>>>
>>> as Andi said they come from different layers, I think it's
>>> better to keep them separated even if they share some fields
> 
> I was just suggesting to make:
>  struct event_struct {
> struct list_head list;
> struct json_event je;
>  }
> 
> No biggie if against this.
> 
> Cheers,
> John


Re: [PATCH v2] perf expr: Force encapsulation on expr_id_data

2020-08-27 Thread kajoljain



On 8/26/20 9:27 PM, Jiri Olsa wrote:
> On Wed, Aug 26, 2020 at 08:30:55AM -0700, Ian Rogers wrote:
>> This patch resolves some undefined behavior where variables in
>> expr_id_data were accessed (for debugging) without being defined. To
>> better enforce the tagged union behavior, the struct is moved into
>> expr.c and accessors provided. Tag values (kinds) are explicitly
>> identified.

Reviewed-By: Kajol Jain

Thanks,
Kajol Jain
>>
>> Signed-off-by: Ian Rogers 
> 
> great, thanks for doing this
> 
> Acked-by: Jiri Olsa 
> 
> jirka
> 


Re: [RFC] perf/core: Fixes hung issue on perf stat command during cpu hotplug

2020-08-26 Thread kajoljain



On 8/26/20 6:51 PM, Arnaldo Carvalho de Melo wrote:
> Em Wed, Aug 26, 2020 at 03:02:36PM +0530, Kajol Jain escreveu:
>> Commit 2ed6edd33a21 ("perf: Add cond_resched() to task_function_call()")
>> added assignment of ret value as -EAGAIN in case function
>> call to 'smp_call_function_single' fails.
>> For non-zero ret value, it did 
>> 'ret = !ret ? data.ret : -EAGAIN;', which always
>> assign -EAGAIN to ret and make second if condition useless.
>>
>> In scenarios like when executing a perf stat with --per-thread option, and 
>> if any of the monitoring cpu goes offline, the 'smp_call_function_single'
>> function could return -ENXIO, and with the above check,
>> task_function_call hung and increases CPU
>> usage (because of repeated 'smp_call_function_single()')
>>
>> Recration scenario:
>>  # perf stat -a --per-thread && (offline a CPU )
> 
> Peter, this is kernel stuff, can you take a look?
> 
> - Arnaldo
>  
>> Patch here removes the tertiary condition added as part of that 
>> commit and added a check for NULL and -EAGAIN.
>>
>> Fixes: 2ed6edd33a21("perf: Add cond_resched() to task_function_call()")
>> Signed-off-by: Kajol Jain 
>> Reported-by: Srikar Dronamraju 
>> ---
>>  kernel/events/core.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/kernel/events/core.c b/kernel/events/core.c
>> index 5bfe8e3c6e44..330c53f7df9c 100644
>> --- a/kernel/events/core.c
>> +++ b/kernel/events/core.c
>> @@ -115,9 +115,9 @@ task_function_call(struct task_struct *p, 
>> remote_function_f func, void *info)
>>  for (;;) {
>>  ret = smp_call_function_single(task_cpu(p), remote_function,
>> , 1);
>> -ret = !ret ? data.ret : -EAGAIN;
>> -
>> -if (ret != -EAGAIN)
>> +if (!ret)
>> +ret = data.ret;
>> +else if (ret != -EAGAIN)
>>  break;
>>  
>>  cond_resched();
>> -- 

Hi,
  Sorry for the confusion, I send wrong version of the patch. We don't have 
else in second
condition.

The right patch changes are:

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 5bfe8e3c6e44..53d960394af9 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -115,8 +115,8 @@ task_function_call(struct task_struct *p, remote_function_f 
func, void *info)
for (;;) {
ret = smp_call_function_single(task_cpu(p), remote_function,
   , 1);
-   ret = !ret ? data.ret : -EAGAIN;
-
+   if (!ret)
+   ret = data.ret;
if (ret != -EAGAIN)
break;

I will again send the patch, please ignore this one.

Thanks,
Kajol Jain
 
>> 2.26.2
>>
> 


Re: [RFC] perf/jevents: Add new structure to pass json fields.

2020-08-26 Thread kajoljain



On 8/26/20 4:30 PM, Jiri Olsa wrote:
> On Tue, Aug 25, 2020 at 09:14:11AM +0100, John Garry wrote:
> 
> SNIP
> 
>>> goto free_strings;
>>> }
>>> -   err = func(data, name, real_event(name, event), desc, long_desc,
>>> -  pmu, unit, perpkg, metric_expr, metric_name,
>>> -  metric_group, deprecated, metric_constraint);
>>> +   je->event = real_event(je->name, je->event);
>>> +   err = func(data, je);
>>>   free_strings:
>>> -   free(event);
>>> -   free(desc);
>>> -   free(name);
>>> -   free(long_desc);
>>> free(extra_desc);
>>> -   free(pmu);
>>> free(filter);
>>> -   free(perpkg);
>>> -   free(deprecated);
>>> -   free(unit);
>>> -   free(metric_expr);
>>> -   free(metric_name);
>>> -   free(metric_group);
>>> -   free(metric_constraint);
>>> free(arch_std);
>>> +   free(je);
>>> if (err)
>>> break;
>>> diff --git a/tools/perf/pmu-events/jevents.h 
>>> b/tools/perf/pmu-events/jevents.h
>>> index 2afc8304529e..e696edf70e9a 100644
>>> --- a/tools/perf/pmu-events/jevents.h
>>> +++ b/tools/perf/pmu-events/jevents.h
>>
>> Somewhat unrelated - this file only seems to be included in jevents.c, so I
>> don't see why it exists...
> 
> ah right.. I won't mind getting rid of it

Hi John and  Jiri
 Thanks for reviewing the patch. I can remove this file and add these 
structure inside jevents.c

Thanks,
Kajol Jain
>  
>>> @@ -2,14 +2,28 @@
>>>   #ifndef JEVENTS_H
>>>   #define JEVENTS_H 1
>>> +#include "pmu-events.h"
>>> +
>>> +struct json_event {
>>> +   char *name;
>>> +   char *event;
>>> +   char *desc;
>>> +   char *topic;
>>> +   char *long_desc;
>>> +   char *pmu;
>>> +   char *unit;
>>> +   char *perpkg;
>>> +   char *metric_expr;
>>> +   char *metric_name;
>>> +   char *metric_group;
>>> +   char *deprecated;
>>> +   char *metric_constraint;
>>
>> This looks very much like struct event_struct, so could look to consolidate:
>>
>> struct event_struct {
>>  struct list_head list;
>>  char *name;
>>  char *event;
>>  char *desc;
>>  char *long_desc;
>>  char *pmu;
>>  char *unit;
>>  char *perpkg;
>>  char *metric_expr;
>>  char *metric_name;
>>  char *metric_group;
>>  char *deprecated;
>>  char *metric_constraint;
>> };
> 
> as Andi said they come from different layers, I think it's
> better to keep them separated even if they share some fields
> 
> thanks,
> jirka
> 


Re: [RFC] perf/jevents: Add new structure to pass json fields.

2020-08-26 Thread kajoljain



On 8/26/20 4:27 PM, Jiri Olsa wrote:
> On Tue, Aug 25, 2020 at 01:10:41PM +0530, Kajol Jain wrote:
> 
> SNIP
> 
>>  }
>>  }
>>  
>> -static int save_arch_std_events(void *data, char *name, char *event,
>> -char *desc, char *long_desc, char *pmu,
>> -char *unit, char *perpkg, char *metric_expr,
>> -char *metric_name, char *metric_group,
>> -char *deprecated, char *metric_constraint)
>> +static int save_arch_std_events(void *data, struct json_event *je)
>>  {
>>  struct event_struct *es;
>>  
>> @@ -485,11 +476,8 @@ static char *real_event(const char *name, char *event)
>>  }
>>  
>>  static int
>> -try_fixup(const char *fn, char *arch_std, char **event, char **desc,
>> -  char **name, char **long_desc, char **pmu, char **filter,
>> -  char **perpkg, char **unit, char **metric_expr, char **metric_name,
>> -  char **metric_group, unsigned long long eventcode,
>> -  char **deprecated, char **metric_constraint)
>> +try_fixup(const char *fn, char *arch_std, unsigned long long eventcode,
>> +  struct json_event *je)
>>  {
>>  /* try to find matching event from arch standard values */
>>  struct event_struct *es;
>> @@ -498,8 +486,7 @@ try_fixup(const char *fn, char *arch_std, char **event, 
>> char **desc,
>>  if (!strcmp(arch_std, es->name)) {
>>  if (!eventcode && es->event) {
>>  /* allow EventCode to be overridden */
>> -free(*event);
>> -*event = NULL;
>> +je->event = NULL;
> 
> should you free je->event in here?

Sure, I will add that.

Thanks,
Kajol Jain
> 
> jirka
> 


Re: [RFC] perf/jevents: Add new structure to pass json fields.

2020-08-26 Thread kajoljain



On 8/26/20 4:26 PM, Jiri Olsa wrote:
> On Tue, Aug 25, 2020 at 01:10:41PM +0530, Kajol Jain wrote:
> 
> SNIP
> 
>>  {
>>  /* try to find matching event from arch standard values */
>>  struct event_struct *es;
>> @@ -498,8 +486,7 @@ try_fixup(const char *fn, char *arch_std, char **event, 
>> char **desc,
>>  if (!strcmp(arch_std, es->name)) {
>>  if (!eventcode && es->event) {
>>  /* allow EventCode to be overridden */
>> -free(*event);
>> -*event = NULL;
>> +je->event = NULL;
>>  }
>>  FOR_ALL_EVENT_STRUCT_FIELDS(TRY_FIXUP_FIELD);
>>  return 0;
>> @@ -513,13 +500,8 @@ try_fixup(const char *fn, char *arch_std, char **event, 
>> char **desc,
>>  
>>  /* Call func with each event in the json file */
>>  int json_events(const char *fn,
>> -  int (*func)(void *data, char *name, char *event, char *desc,
>> -  char *long_desc,
>> -  char *pmu, char *unit, char *perpkg,
>> -  char *metric_expr,
>> -  char *metric_name, char *metric_group,
>> -  char *deprecated, char *metric_constraint),
>> -  void *data)
>> +int (*func)(void *data, struct json_event *je),
>> +void *data)
>>  {
>>  int err;
>>  size_t size;
>> @@ -537,24 +519,16 @@ int json_events(const char *fn,
>>  EXPECT(tokens->type == JSMN_ARRAY, tokens, "expected top level array");
>>  tok = tokens + 1;
>>  for (i = 0; i < tokens->size; i++) {
>> -char *event = NULL, *desc = NULL, *name = NULL;
>> -char *long_desc = NULL;
>>  char *extra_desc = NULL;
>> -char *pmu = NULL;
>>  char *filter = NULL;
>> -char *perpkg = NULL;
>> -char *unit = NULL;
>> -char *metric_expr = NULL;
>> -char *metric_name = NULL;
>> -char *metric_group = NULL;
>> -char *deprecated = NULL;
>> -char *metric_constraint = NULL;
>> +struct json_event *je;
>>  char *arch_std = NULL;
>>  unsigned long long eventcode = 0;
>>  struct msrmap *msr = NULL;
>>  jsmntok_t *msrval = NULL;
>>  jsmntok_t *precise = NULL;
>>  jsmntok_t *obj = tok++;
>> +je = (struct json_event *)calloc(1, sizeof(struct json_event));
> 
> hum, you don't check je pointer in here.. but does it need to be allocated?
> looks like you could just have je on stack as well..

Hi Jiri,
   Yes I will add check for je pointer here.The reason for allocating memory to 
'je' is,
later we are actually referring one by one to its field and in case if won't 
allocate memory
we will get segmentaion fault as otherwise je will be NULL. Please let me know 
if I am
getting correct.

Thanks,
Kajol Jain

> 
> thanks,
> jirka
> 


Re: [RFC] perf/jevents: Add new structure to pass json fields.

2020-08-26 Thread kajoljain



On 8/25/20 9:17 PM, Andi Kleen wrote:
> On Tue, Aug 25, 2020 at 01:10:41PM +0530, Kajol Jain wrote:
>> This patch adds new structure called 'json_event' inside jevents.h
>> file to improve the callback prototype inside jevent files.
>> Initially, whenever user want to add new field, they need to update
>> in all function callback which make it more and more complex with
>> increased number of parmeters.
>> With this change, we just need to add it in new structure 'json_event'.
> 
> Looks good to me. Thanks.
> 
> I wouldn't consolidate with event_struct, these are logically
> different layers.
> 
> Reviewed-by: Andi Kleen 
> 
Hi Andi,
   Thanks for reviewing the patch.

Thanks,
Kajol Jain


Re: [RFC] perf/jevents: Add new structure to pass json fields.

2020-08-26 Thread kajoljain



On 8/26/20 4:27 PM, Jiri Olsa wrote:
> On Tue, Aug 25, 2020 at 01:10:41PM +0530, Kajol Jain wrote:
> 
> SNIP
> 
>> diff --git a/tools/perf/pmu-events/jevents.h 
>> b/tools/perf/pmu-events/jevents.h
>> index 2afc8304529e..e696edf70e9a 100644
>> --- a/tools/perf/pmu-events/jevents.h
>> +++ b/tools/perf/pmu-events/jevents.h
>> @@ -2,14 +2,28 @@
>>  #ifndef JEVENTS_H
>>  #define JEVENTS_H 1
>>  
>> +#include "pmu-events.h"
>> +
>> +struct json_event {
>> +char *name;
>> +char *event;
>> +char *desc;
>> +char *topic;
>> +char *long_desc;
>> +char *pmu;
>> +char *unit;
>> +char *perpkg;
>> +char *metric_expr;
>> +char *metric_name;
>> +char *metric_group;
>> +char *deprecated;
>> +char *metric_constraint;
>> +};
>> +
>>  int json_events(const char *fn,
>> -int (*func)(void *data, char *name, char *event, char *desc,
>> -char *long_desc,
>> -char *pmu,
>> -char *unit, char *perpkg, char *metric_expr,
>> -char *metric_name, char *metric_group,
>> -char *deprecated, char *metric_constraint),
>> -void *data);
>> +int (*func)(void *data, struct json_event *je),
>> +void *data);
> 
> please also add typedef for the function,
> it's used in other places as well

Ok I will add that part.

Thanks,
Kajol Jain
> 
> thanks,
> jirka
> 


Re: [PATCH v5 1/3] perf jevents: Add support for parsing perchip/percore events

2020-08-18 Thread kajoljain



On 8/16/20 10:05 PM, Andi Kleen wrote:
>> @@ -321,7 +331,7 @@ static void print_events_table_prefix(FILE *fp, const 
>> char *tblname)
>>  static int print_events_table_entry(void *data, char *name, char *event,
>>  char *desc, char *long_desc,
>>  char *pmu, char *unit, char *perpkg,
>> -char *metric_expr,
>> +char *metric_expr, char *aggr_mode,
>>  char *metric_name, char *metric_group,
>>  char *deprecated, char *metric_constraint)
> 
> We should really define a struct now to pass the parameters,
> the callback prototype is getting ridiculous.
> 
> I know it's my fault originally, but sorry you probably have to do it
> because you are touching it last.

Hi Andi,
   I will look into it.

Thanks,
Kajol Jain
> 
> -Andi
> 


Re: [PATCH] perf stat: update POWER9 metrics to utilize other metrics

2020-08-13 Thread kajoljain



On 8/14/20 9:13 AM, Ian Rogers wrote:
> On Thu, Aug 13, 2020 at 3:21 PM Paul A. Clarke  wrote:
>>
>> These changes take advantage of the new capability added in
>> merge commit 00e4db51259a5f936fec1424b884f029479d3981
>> "Allow using computed metrics in calculating other metrics".
>>
>> The net is a simplification of the expressions for a handful
>> of metrics, but no functional change.
>>
>> Signed-off-by: Paul A. Clarke 
> 

Hi Paul,
  The patch looks good to me.

Reviewed-by: Kajol Jain

Thanks,
Kajol Jain

> Acked-by: Ian Rogers 
> (Re-sent with plain text enabled to avoid lkml bounce)
> 
> Thanks,
> Ian
> 
> 
>>
>> ---
>>  .../arch/powerpc/power9/metrics.json  | 48 +--
>>  1 file changed, 24 insertions(+), 24 deletions(-)
>>
>> diff --git a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json 
>> b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
>> index 80816d6402e9..f8784c608479 100644
>> --- a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
>> +++ b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
>> @@ -60,7 +60,7 @@
>>  },
>>  {
>>  "BriefDescription": "Stalls due to short latency decimal floating 
>> ops.",
>> -"MetricExpr": "(PM_CMPLU_STALL_DFU - 
>> PM_CMPLU_STALL_DFLONG)/PM_RUN_INST_CMPL",
>> +"MetricExpr": "dfu_stall_cpi - dflong_stall_cpi",
>>  "MetricGroup": "cpi_breakdown",
>>  "MetricName": "dfu_other_stall_cpi"
>>  },
>> @@ -72,7 +72,7 @@
>>  },
>>  {
>>  "BriefDescription": "Completion stall by Dcache miss which resolved 
>> off node memory/cache",
>> -"MetricExpr": "(PM_CMPLU_STALL_DMISS_L3MISS - 
>> PM_CMPLU_STALL_DMISS_L21_L31 - PM_CMPLU_STALL_DMISS_LMEM - 
>> PM_CMPLU_STALL_DMISS_REMOTE)/PM_RUN_INST_CMPL",
>> +"MetricExpr": "dmiss_non_local_stall_cpi - dmiss_remote_stall_cpi",
>>  "MetricGroup": "cpi_breakdown",
>>  "MetricName": "dmiss_distant_stall_cpi"
>>  },
>> @@ -90,7 +90,7 @@
>>  },
>>  {
>>  "BriefDescription": "Completion stall due to cache miss that 
>> resolves in the L2 or L3 without conflict",
>> -"MetricExpr": "(PM_CMPLU_STALL_DMISS_L2L3 - 
>> PM_CMPLU_STALL_DMISS_L2L3_CONFLICT)/PM_RUN_INST_CMPL",
>> +"MetricExpr": "dmiss_l2l3_stall_cpi - 
>> dmiss_l2l3_conflict_stall_cpi",
>>  "MetricGroup": "cpi_breakdown",
>>  "MetricName": "dmiss_l2l3_noconflict_stall_cpi"
>>  },
>> @@ -114,7 +114,7 @@
>>  },
>>  {
>>  "BriefDescription": "Completion stall by Dcache miss which resolved 
>> outside of local memory",
>> -"MetricExpr": "(PM_CMPLU_STALL_DMISS_L3MISS - 
>> PM_CMPLU_STALL_DMISS_L21_L31 - PM_CMPLU_STALL_DMISS_LMEM)/PM_RUN_INST_CMPL",
>> +"MetricExpr": "dmiss_l3miss_stall_cpi - dmiss_l21_l31_stall_cpi - 
>> dmiss_lmem_stall_cpi",
>>  "MetricGroup": "cpi_breakdown",
>>  "MetricName": "dmiss_non_local_stall_cpi"
>>  },
>> @@ -126,7 +126,7 @@
>>  },
>>  {
>>  "BriefDescription": "Stalls due to short latency double precision 
>> ops.",
>> -"MetricExpr": "(PM_CMPLU_STALL_DP - 
>> PM_CMPLU_STALL_DPLONG)/PM_RUN_INST_CMPL",
>> +"MetricExpr": "dp_stall_cpi - dplong_stall_cpi",
>>  "MetricGroup": "cpi_breakdown",
>>  "MetricName": "dp_other_stall_cpi"
>>  },
>> @@ -155,7 +155,7 @@
>>  "MetricName": "emq_full_stall_cpi"
>>  },
>>  {
>> -"MetricExpr": "(PM_CMPLU_STALL_ERAT_MISS + 
>> PM_CMPLU_STALL_EMQ_FULL)/PM_RUN_INST_CMPL",
>> +"MetricExpr": "erat_miss_stall_cpi + emq_full_stall_cpi",
>>  "MetricGroup": "cpi_breakdown",
>>  "MetricName": "emq_stall_cpi"
>>  },
>> @@ -173,7 +173,7 @@
>>  },
>>  {
>>  "BriefDescription": "Completion stall due to execution units for 
>> other reasons.",
>> -"MetricExpr": "(PM_CMPLU_STALL_EXEC_UNIT - PM_CMPLU_STALL_FXU - 
>> PM_CMPLU_STALL_DP - PM_CMPLU_STALL_DFU - PM_CMPLU_STALL_PM - 
>> PM_CMPLU_STALL_CRYPTO - PM_CMPLU_STALL_VFXU - 
>> PM_CMPLU_STALL_VDP)/PM_RUN_INST_CMPL",
>> +"MetricExpr": "exec_unit_stall_cpi - scalar_stall_cpi - 
>> vector_stall_cpi",
>>  "MetricGroup": "cpi_breakdown",
>>  "MetricName": "exec_unit_other_stall_cpi"
>>  },
>> @@ -197,7 +197,7 @@
>>  },
>>  {
>>  "BriefDescription": "Stalls due to short latency integer ops",
>> -"MetricExpr": "(PM_CMPLU_STALL_FXU - 
>> PM_CMPLU_STALL_FXLONG)/PM_RUN_INST_CMPL",
>> +"MetricExpr": "fxu_stall_cpi - fxlong_stall_cpi",
>>  "MetricGroup": "cpi_breakdown",
>>  "MetricName": "fxu_other_stall_cpi"
>>  },
>> @@ -221,7 +221,7 @@
>>  },
>>  {
>>  "BriefDescription": "Instruction Completion Table other stalls",
>> -"MetricExpr": "(PM_ICT_NOSLOT_CYC - PM_ICT_NOSLOT_IC_MISS - 
>> PM_ICT_NOSLOT_BR_MPRED_ICMISS - PM_ICT_NOSLOT_BR_MPRED - 
>> PM_ICT_NOSLOT_DISP_HELD)/PM_RUN_INST_CMPL",
>> +"MetricExpr": 

Re: [PATCH 16/19] perf metric: Make compute_single function more precise

2020-07-28 Thread kajoljain



On 7/28/20 10:56 PM, Ian Rogers wrote:
> On Tue, Jul 28, 2020 at 5:36 AM Arnaldo Carvalho de Melo
>  wrote:
>>
>> Em Sun, Jul 19, 2020 at 08:13:17PM +0200, Jiri Olsa escreveu:
>>> So far compute_single function relies on the fact, that
>>> there's only single metric defined within evlist in all
>>> tests. In following patch we will add test for metric
>>> group, so we need to be able to compute metric by given
>>> name.
>>>
>>> Adding the name argument to compute_single and iterating
>>> evlist and evsel's expression to find the given metric.
>>
>> Applied, thanks.
>>
>> Ian, Kajol, I didn't notice your Acked-by or Reviewed-by, like for the
>> other patches, can you check?
> 
> 
> Acked-by: Ian Rogers 

Reviewed-By: Kajol Jain

Thanks,
Kajol Jain
> 
> Thanks,
> Ian
> 
>> - Arnaldo
>>
>>> Signed-off-by: Jiri Olsa 
>>> ---
>>>  tools/perf/tests/parse-metric.c | 22 +-
>>>  1 file changed, 13 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/tools/perf/tests/parse-metric.c 
>>> b/tools/perf/tests/parse-metric.c
>>> index 01370ccb9ed9..5ac32f80f8ea 100644
>>> --- a/tools/perf/tests/parse-metric.c
>>> +++ b/tools/perf/tests/parse-metric.c
>>> @@ -108,17 +108,21 @@ static void load_runtime_stat(struct runtime_stat 
>>> *st, struct evlist *evlist,
>>>  }
>>>
>>>  static double compute_single(struct rblist *metric_events, struct evlist 
>>> *evlist,
>>> -  struct runtime_stat *st)
>>> +  struct runtime_stat *st, const char *name)
>>>  {
>>> - struct evsel *evsel = evlist__first(evlist);
>>> + struct metric_expr *mexp;
>>>   struct metric_event *me;
>>> + struct evsel *evsel;
>>>
>>> - me = metricgroup__lookup(metric_events, evsel, false);
>>> - if (me != NULL) {
>>> - struct metric_expr *mexp;
>>> -
>>> - mexp = list_first_entry(>head, struct metric_expr, nd);
>>> - return test_generic_metric(mexp, 0, st);
>>> + evlist__for_each_entry(evlist, evsel) {
>>> + me = metricgroup__lookup(metric_events, evsel, false);
>>> + if (me != NULL) {
>>> + list_for_each_entry (mexp, >head, nd) {
>>> + if (strcmp(mexp->metric_name, name))
>>> + continue;
>>> + return test_generic_metric(mexp, 0, st);
>>> + }
>>> + }
>>>   }
>>>   return 0.;
>>>  }
>>> @@ -162,7 +166,7 @@ static int compute_metric(const char *name, struct 
>>> value *vals, double *ratio)
>>>   load_runtime_stat(, evlist, vals);
>>>
>>>   /* And execute the metric */
>>> - *ratio = compute_single(_events, evlist, );
>>> + *ratio = compute_single(_events, evlist, , name);
>>>
>>>   /* ... clenup. */
>>>   metricgroup__rblist_exit(_events);
>>> --
>>> 2.25.4
>>>
>>
>> --
>>
>> - Arnaldo


Re: [PATCH v4 0/5] powerpc/perf: Add json file support for hv_24x7 core level events

2020-07-26 Thread kajoljain



On 7/21/20 1:01 AM, Arnaldo Carvalho de Melo wrote:
> Em Mon, Jul 20, 2020 at 09:21:33PM +0200, Jiri Olsa escreveu:
>> On Mon, Jul 20, 2020 at 12:31:22PM +0530, Kajol Jain wrote:
>>> Patchset enhance current runtime parameter support. It introduces new
>>> fields like "PerChip" and "PerCore" similar to the field "PerPkg" which is
>>> used to specify perpkg events. 
>>>
>>> The "PerCore" and "PerChip" specifies whether its core or chip events.
>>> Based on which we can decide which runtime parameter user want to
>>> access. Now character  '?' can refers different parameter based on user
>>> requirement.
>>>
>>> Initially, every time we want to add new terms like chip, core, thread
>>> etc, we need to create corrsponding fields in pmu_events and event
>>> struct.
>>> This patchset adds an enum called 'aggr_mode_class' which store all these
>>> aggregation like perpkg/percore. It also adds new field 'AggregationMode'
>>> to capture these terms.
>>> Now, if user wants to add any new term, they just need to add it in
>>> the enum defined. I try to test it with  my current setup.
>>>
>>> I also need to replace PerPkg field to AggregationMode in all the
>>> x86 uncore json files. It will great if Andi and team can test it
>>> and let me know if they have any concerns.
>>>
>>> Changelog:
>>> v3 -> v4:
>>> - Include pmu-events.h header file in jevents.c and remove
>>>   redecalaration of enum aggr_mode_class as Suggested by Jiri.
>>> - Add Acked-by tag.
>>
>> looks good to me, but still missing reaction from people maintaining
>> intel's jsons
> 
> Yeah, since this is something trying to be generic enough to describe
> events from different arches, we should not double-fail into
> generalizing this :-\

Hi,
   Yes that make sense. In this patchset we are not doing any logical change 
from intel side,
as in all the json file "PerPkg" value map to '1', we are using same value in 
the
enum to not break that use case. And just replacing 'PerPkg' to new added field
`AggregationMode'. 

But you are right, it will be good to have Ack from intel people. Any comments 
how we can push these
changes?

Thanks,
Kajol Jain
> 
> - Arnaldo
> 


Re: [PATCH 18/19] perf metric: Rename struct egroup to metric

2020-07-26 Thread kajoljain



On 7/19/20 11:43 PM, Jiri Olsa wrote:
> Renaming struct egroup to metric, because it seems
> to make more sense. Plus renaming all the variables
> that hold egroup to appropriate names.
> 
> Acked-by: Ian Rogers 
> Signed-off-by: Jiri Olsa 
> ---

Reviewed-By : Kajol Jain

Thanks,
Kajol Jain
>  tools/perf/util/metricgroup.c | 142 +-
>  1 file changed, 71 insertions(+), 71 deletions(-)
> 
> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
> index 2a45ee94fd61..9d5fff36042d 100644
> --- a/tools/perf/util/metricgroup.c
> +++ b/tools/perf/util/metricgroup.c
> @@ -115,7 +115,7 @@ struct metric_ref_node {
>   struct list_head list;
>  };
>  
> -struct egroup {
> +struct metric {
>   struct list_head nd;
>   struct expr_parse_ctx pctx;
>   const char *metric_name;
> @@ -262,7 +262,7 @@ static int metricgroup__setup_events(struct list_head 
> *groups,
>   struct metric_expr *expr;
>   int i = 0;
>   int ret = 0;
> - struct egroup *eg;
> + struct metric *m;
>   struct evsel *evsel, *tmp;
>   unsigned long *evlist_used;
>  
> @@ -270,23 +270,23 @@ static int metricgroup__setup_events(struct list_head 
> *groups,
>   if (!evlist_used)
>   return -ENOMEM;
>  
> - list_for_each_entry (eg, groups, nd) {
> + list_for_each_entry (m, groups, nd) {
>   struct evsel **metric_events;
>   struct metric_ref *metric_refs = NULL;
>  
>   metric_events = calloc(sizeof(void *),
> - hashmap__size(>pctx.ids) + 1);
> + hashmap__size(>pctx.ids) + 1);
>   if (!metric_events) {
>   ret = -ENOMEM;
>   break;
>   }
> - evsel = find_evsel_group(perf_evlist, >pctx,
> + evsel = find_evsel_group(perf_evlist, >pctx,
>metric_no_merge,
> -  eg->has_constraint, metric_events,
> +  m->has_constraint, metric_events,
>evlist_used);
>   if (!evsel) {
>   pr_debug("Cannot resolve %s: %s\n",
> - eg->metric_name, eg->metric_expr);
> + m->metric_name, m->metric_expr);
>   free(metric_events);
>   continue;
>   }
> @@ -309,10 +309,10 @@ static int metricgroup__setup_events(struct list_head 
> *groups,
>* Collect and store collected nested expressions
>* for metric processing.
>*/
> - if (eg->metric_refs_cnt) {
> + if (m->metric_refs_cnt) {
>   struct metric_ref_node *ref;
>  
> - metric_refs = zalloc(sizeof(struct metric_ref) * 
> (eg->metric_refs_cnt + 1));
> + metric_refs = zalloc(sizeof(struct metric_ref) * 
> (m->metric_refs_cnt + 1));
>   if (!metric_refs) {
>   ret = -ENOMEM;
>   free(metric_events);
> @@ -320,7 +320,7 @@ static int metricgroup__setup_events(struct list_head 
> *groups,
>   }
>  
>   i = 0;
> - list_for_each_entry(ref, >metric_refs, list) {
> + list_for_each_entry(ref, >metric_refs, list) {
>   /*
>* Intentionally passing just const char 
> pointers,
>* originally from 'struct pmu_event' object.
> @@ -334,11 +334,11 @@ static int metricgroup__setup_events(struct list_head 
> *groups,
>   };
>  
>   expr->metric_refs = metric_refs;
> - expr->metric_expr = eg->metric_expr;
> - expr->metric_name = eg->metric_name;
> - expr->metric_unit = eg->metric_unit;
> + expr->metric_expr = m->metric_expr;
> + expr->metric_name = m->metric_name;
> + expr->metric_unit = m->metric_unit;
>   expr->metric_events = metric_events;
> - expr->runtime = eg->runtime;
> + expr->runtime = m->runtime;
>   list_add(>nd, >head);
>   }
>  
> @@ -643,41 +643,41 @@ static int __add_metric(struct list_head *group_list,
>   struct pmu_event *pe,
>   bool metric_no_group,
>   int runtime,
> - struct egroup **egp,
> + struct metric **mp,
>   struct expr_id *parent,
>   struct expr_ids *ids)
>  {
>   struct metric_ref_node *ref;
> - struct egroup *eg;
> + struct metric *m;
>  
> - if (*egp == NULL) {
> + if (*mp == NULL) {
>   /*
>* We got in here for the parent 

Re: [PATCH 19/19] perf metric: Rename group_list to metric_list

2020-07-26 Thread kajoljain



On 7/19/20 11:43 PM, Jiri Olsa wrote:
> Following the previous change that rename egroup
> to metric, there's no reason to call the list
> 'group_list' anymore, renaming it to metric_list.
> 
> Signed-off-by: Jiri Olsa 

Reviewed-By : Kajol Jain

Thanks,
Kajol Jain
> ---
>  tools/perf/util/metricgroup.c | 42 +--
>  1 file changed, 21 insertions(+), 21 deletions(-)
> 
> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
> index 9d5fff36042d..6f179b9903a0 100644
> --- a/tools/perf/util/metricgroup.c
> +++ b/tools/perf/util/metricgroup.c
> @@ -639,7 +639,7 @@ int __weak arch_get_runtimeparam(void)
>   return 1;
>  }
>  
> -static int __add_metric(struct list_head *group_list,
> +static int __add_metric(struct list_head *metric_list,
>   struct pmu_event *pe,
>   bool metric_no_group,
>   int runtime,
> @@ -726,13 +726,13 @@ static int __add_metric(struct list_head *group_list,
>   if (m->metric_refs_cnt)
>   return 0;
>  
> - if (list_empty(group_list))
> - list_add(>nd, group_list);
> + if (list_empty(metric_list))
> + list_add(>nd, metric_list);
>   else {
>   struct list_head *pos;
>  
>   /* Place the largest groups at the front. */
> - list_for_each_prev(pos, group_list) {
> + list_for_each_prev(pos, metric_list) {
>   struct metric *old = list_entry(pos, struct metric, nd);
>  
>   if (hashmap__size(>pctx.ids) <=
> @@ -813,7 +813,7 @@ static int recursion_check(struct metric *m, const char 
> *id, struct expr_id **pa
>   return p->id ? 0 : -ENOMEM;
>  }
>  
> -static int add_metric(struct list_head *group_list,
> +static int add_metric(struct list_head *metric_list,
> struct pmu_event *pe,
> bool metric_no_group,
> struct metric **mp,
> @@ -822,7 +822,7 @@ static int add_metric(struct list_head *group_list,
>  
>  static int resolve_metric(struct metric *m,
> bool metric_no_group,
> -   struct list_head *group_list,
> +   struct list_head *metric_list,
> struct pmu_events_map *map,
> struct expr_ids *ids)
>  {
> @@ -854,7 +854,7 @@ static int resolve_metric(struct metric *m,
>   expr__del_id(>pctx, cur->key);
>  
>   /* ... and it gets resolved to the parent context. */
> - ret = add_metric(group_list, pe, metric_no_group, , 
> parent, ids);
> + ret = add_metric(metric_list, pe, metric_no_group, , 
> parent, ids);
>   if (ret)
>   return ret;
>  
> @@ -869,7 +869,7 @@ static int resolve_metric(struct metric *m,
>   return 0;
>  }
>  
> -static int add_metric(struct list_head *group_list,
> +static int add_metric(struct list_head *metric_list,
> struct pmu_event *pe,
> bool metric_no_group,
> struct metric **m,
> @@ -881,7 +881,7 @@ static int add_metric(struct list_head *group_list,
>   pr_debug("metric expr %s for %s\n", pe->metric_expr, pe->metric_name);
>  
>   if (!strstr(pe->metric_expr, "?")) {
> - ret = __add_metric(group_list, pe, metric_no_group, 1, m, 
> parent, ids);
> + ret = __add_metric(metric_list, pe, metric_no_group, 1, m, 
> parent, ids);
>   } else {
>   int j, count;
>  
> @@ -889,11 +889,11 @@ static int add_metric(struct list_head *group_list,
>  
>   /* This loop is added to create multiple
>* events depend on count value and add
> -  * those events to group_list.
> +  * those events to metric_list.
>*/
>  
>   for (j = 0; j < count && !ret; j++) {
> - ret = __add_metric(group_list, pe, metric_no_group, j, 
> m, parent, ids);
> + ret = __add_metric(metric_list, pe, metric_no_group, j, 
> m, parent, ids);
>   }
>   }
>  
> @@ -902,7 +902,7 @@ static int add_metric(struct list_head *group_list,
>  
>  static int metricgroup__add_metric(const char *metric, bool metric_no_group,
>  struct strbuf *events,
> -struct list_head *group_list,
> +struct list_head *metric_list,
>  struct pmu_events_map *map)
>  
>  {
> @@ -948,14 +948,14 @@ static int metricgroup__add_metric(const char *metric, 
> bool metric_no_group,
>   }
>   }
>  
> - list_splice(, group_list);
> + list_splice(, metric_list);
>   expr_ids__exit();
>   return 0;
>  }
>  
>  static int metricgroup__add_metric_list(const char *list, bool 
> metric_no_group,
>  

Re: [PATCH 15/19] perf metric: Add recursion check when processing nested metrics

2020-07-26 Thread kajoljain



On 7/20/20 4:10 AM, Ian Rogers wrote:
> On Sun, Jul 19, 2020 at 11:14 AM Jiri Olsa  wrote:
>>
>> Keeping the stack of nested metrics via 'struct expr_id' objects
>> and checking if we are in recursion via already processed metric.
>>
>> The stack is implemented as static array within the struct egroup
>> with 100 entries, which should be enough nesting depth for any
>> metric we have or plan to have at the moment.
>>
>> Adding test that simulates the recursion and checks we can
>> detect it.
>>
>> Signed-off-by: Jiri Olsa 
> 
> Acked-by: Ian Rogers 
> 

Reviewed-By : Kajol Jain

Thanks,
Kajol Jain
> Thanks,
> Ian
> 
>> ---
>>  tools/perf/tests/parse-metric.c |  34 +-
>>  tools/perf/util/expr.c  |   2 +
>>  tools/perf/util/expr.h  |   9 ++-
>>  tools/perf/util/metricgroup.c   | 117 +---
>>  4 files changed, 149 insertions(+), 13 deletions(-)
>>
>> diff --git a/tools/perf/tests/parse-metric.c 
>> b/tools/perf/tests/parse-metric.c
>> index aa4d5a9f09a8..01370ccb9ed9 100644
>> --- a/tools/perf/tests/parse-metric.c
>> +++ b/tools/perf/tests/parse-metric.c
>> @@ -57,6 +57,18 @@ static struct pmu_event pme_test[] = {
>> .metric_expr= "d_ratio(dcache_l2_all_miss, dcache_l2_all)",
>> .metric_name= "DCache_L2_Misses",
>>  },
>> +{
>> +   .metric_expr= "ipc + m2",
>> +   .metric_name= "M1",
>> +},
>> +{
>> +   .metric_expr= "ipc + m1",
>> +   .metric_name= "M2",
>> +},
>> +{
>> +   .metric_expr= "1/m3",
>> +   .metric_name= "M3",
>> +}
>>  };
>>
>>  static struct pmu_events_map map = {
>> @@ -139,8 +151,8 @@ static int compute_metric(const char *name, struct value 
>> *vals, double *ratio)
>> err = metricgroup__parse_groups_test(evlist, , name,
>>  false, false,
>>  _events);
>> -
>> -   TEST_ASSERT_VAL("failed to parse metric", err == 0);
>> +   if (err)
>> +   return err;
>>
>> if (perf_evlist__alloc_stats(evlist, false))
>> return -1;
>> @@ -264,11 +276,29 @@ static int test_dcache_l2(void)
>> return 0;
>>  }
>>
>> +static int test_recursion_fail(void)
>> +{
>> +   double ratio;
>> +   struct value vals[] = {
>> +   { .event = "inst_retired.any",.val = 300 },
>> +   { .event = "cpu_clk_unhalted.thread", .val = 200 },
>> +   { 0 },
>> +   };
>> +
>> +   TEST_ASSERT_VAL("failed to find recursion",
>> +   compute_metric("M1", vals, ) == -1);
>> +
>> +   TEST_ASSERT_VAL("failed to find recursion",
>> +   compute_metric("M3", vals, ) == -1);
>> +   return 0;
>> +}
>> +
>>  int test__parse_metric(struct test *test __maybe_unused, int subtest 
>> __maybe_unused)
>>  {
>> TEST_ASSERT_VAL("IPC failed", test_ipc() == 0);
>> TEST_ASSERT_VAL("frontend failed", test_frontend() == 0);
>> TEST_ASSERT_VAL("cache_miss_cycles failed", test_cache_miss_cycles() 
>> == 0);
>> TEST_ASSERT_VAL("DCache_L2 failed", test_dcache_l2() == 0);
>> +   TEST_ASSERT_VAL("recursion fail failed", test_recursion_fail() == 0);
>> return 0;
>>  }
>> diff --git a/tools/perf/util/expr.c b/tools/perf/util/expr.c
>> index a346ca590513..53482ef53c41 100644
>> --- a/tools/perf/util/expr.c
>> +++ b/tools/perf/util/expr.c
>> @@ -47,6 +47,8 @@ int expr__add_id(struct expr_parse_ctx *ctx, const char 
>> *id)
>> if (!data_ptr)
>> return -ENOMEM;
>>
>> +   data_ptr->parent = ctx->parent;
>> +
>> ret = hashmap__set(>ids, id, data_ptr,
>>(const void **)_key, (void **)_data);
>> if (ret)
>> diff --git a/tools/perf/util/expr.h b/tools/perf/util/expr.h
>> index 9ed208d93418..fc2b5e824a66 100644
>> --- a/tools/perf/util/expr.h
>> +++ b/tools/perf/util/expr.h
>> @@ -13,8 +13,14 @@
>>
>>  struct metric_ref;
>>
>> +struct expr_id {
>> +   char*id;
>> +   struct expr_id  *parent;
>> +};
>> +
>>  struct expr_parse_ctx {
>> -   struct hashmap ids;
>> +   struct hashmap   ids;
>> +   struct expr_id  *parent;
>>  };
>>
>>  struct expr_id_data {
>> @@ -25,6 +31,7 @@ struct expr_id_data {
>> const char *metric_expr;
>> bool counted;
>> } ref;
>> +   struct expr_id  *parent;
>> };
>>
>> bool is_ref;
>> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
>> index 332414d93f7a..2a45ee94fd61 100644
>> --- a/tools/perf/util/metricgroup.c
>> +++ b/tools/perf/util/metricgroup.c
>> @@ -24,6 +24,7 @@
>>  #include 
>>  #include 
>>  #include "util.h"
>> +#include 
>>
>>  struct metric_event *metricgroup__lookup(struct rblist *metric_events,
>>  struct evsel *evsel,
>> @@ -126,6 +127,28 @@ struct egroup {
>> 

Re: [PATCH 17/19] perf metric: Add metric group test

2020-07-26 Thread kajoljain



On 7/20/20 4:11 AM, Ian Rogers wrote:
> On Sun, Jul 19, 2020 at 11:14 AM Jiri Olsa  wrote:
>>
>> Adding test for metric group plus compute_metric_group
>> function to get metrics values within the group.
>>
>> Signed-off-by: Jiri Olsa 
> 
> Acked-by: Ian Rogers 

Reviewed-By : Kajol Jain

Thanks,
Kajol Jain

> 
> Thanks,
> Ian
> 
>> ---
>>  tools/perf/tests/parse-metric.c | 48 +++--
>>  1 file changed, 46 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/perf/tests/parse-metric.c 
>> b/tools/perf/tests/parse-metric.c
>> index 5ac32f80f8ea..f2ba5b2c5557 100644
>> --- a/tools/perf/tests/parse-metric.c
>> +++ b/tools/perf/tests/parse-metric.c
>> @@ -18,6 +18,7 @@ static struct pmu_event pme_test[] = {
>>  {
>> .metric_expr= "inst_retired.any / cpu_clk_unhalted.thread",
>> .metric_name= "IPC",
>> +   .metric_group   = "group1",
>>  },
>>  {
>> .metric_expr= "idq_uops_not_delivered.core / (4 * (( ( 
>> cpu_clk_unhalted.thread / 2 ) * "
>> @@ -35,6 +36,7 @@ static struct pmu_event pme_test[] = {
>>  {
>> .metric_expr= "(dcache_miss_cpi + icache_miss_cycles)",
>> .metric_name= "cache_miss_cycles",
>> +   .metric_group   = "group1",
>>  },
>>  {
>> .metric_expr= "l2_rqsts.demand_data_rd_hit + l2_rqsts.pf_hit + 
>> l2_rqsts.rfo_hit",
>> @@ -127,7 +129,9 @@ static double compute_single(struct rblist 
>> *metric_events, struct evlist *evlist
>> return 0.;
>>  }
>>
>> -static int compute_metric(const char *name, struct value *vals, double 
>> *ratio)
>> +static int __compute_metric(const char *name, struct value *vals,
>> +   const char *name1, double *ratio1,
>> +   const char *name2, double *ratio2)
>>  {
>> struct rblist metric_events = {
>> .nr_entries = 0,
>> @@ -166,7 +170,10 @@ static int compute_metric(const char *name, struct 
>> value *vals, double *ratio)
>> load_runtime_stat(, evlist, vals);
>>
>> /* And execute the metric */
>> -   *ratio = compute_single(_events, evlist, , name);
>> +   if (name1 && ratio1)
>> +   *ratio1 = compute_single(_events, evlist, , name1);
>> +   if (name2 && ratio2)
>> +   *ratio2 = compute_single(_events, evlist, , name2);
>>
>> /* ... clenup. */
>> metricgroup__rblist_exit(_events);
>> @@ -177,6 +184,18 @@ static int compute_metric(const char *name, struct 
>> value *vals, double *ratio)
>> return 0;
>>  }
>>
>> +static int compute_metric(const char *name, struct value *vals, double 
>> *ratio)
>> +{
>> +   return __compute_metric(name, vals, name, ratio, NULL, NULL);
>> +}
>> +
>> +static int compute_metric_group(const char *name, struct value *vals,
>> +   const char *name1, double *ratio1,
>> +   const char *name2, double *ratio2)
>> +{
>> +   return __compute_metric(name, vals, name1, ratio1, name2, ratio2);
>> +}
>> +
>>  static int test_ipc(void)
>>  {
>> double ratio;
>> @@ -297,6 +316,30 @@ static int test_recursion_fail(void)
>> return 0;
>>  }
>>
>> +static int test_metric_group(void)
>> +{
>> +   double ratio1, ratio2;
>> +   struct value vals[] = {
>> +   { .event = "cpu_clk_unhalted.thread", .val = 200 },
>> +   { .event = "l1d-loads-misses",.val = 300 },
>> +   { .event = "l1i-loads-misses",.val = 200 },
>> +   { .event = "inst_retired.any",.val = 400 },
>> +   { 0 },
>> +   };
>> +
>> +   TEST_ASSERT_VAL("failed to find recursion",
>> +   compute_metric_group("group1", vals,
>> +"IPC", ,
>> +"cache_miss_cycles", ) 
>> == 0);
>> +
>> +   TEST_ASSERT_VAL("group IPC failed, wrong ratio",
>> +   ratio1 == 2.0);
>> +
>> +   TEST_ASSERT_VAL("group cache_miss_cycles failed, wrong ratio",
>> +   ratio2 == 1.25);
>> +   return 0;
>> +}
>> +
>>  int test__parse_metric(struct test *test __maybe_unused, int subtest 
>> __maybe_unused)
>>  {
>> TEST_ASSERT_VAL("IPC failed", test_ipc() == 0);
>> @@ -304,5 +347,6 @@ int test__parse_metric(struct test *test __maybe_unused, 
>> int subtest __maybe_unu
>> TEST_ASSERT_VAL("cache_miss_cycles failed", test_cache_miss_cycles() 
>> == 0);
>> TEST_ASSERT_VAL("DCache_L2 failed", test_dcache_l2() == 0);
>> TEST_ASSERT_VAL("recursion fail failed", test_recursion_fail() == 0);
>> +   TEST_ASSERT_VAL("test metric group", test_metric_group() == 0);
>> return 0;
>>  }
>> --
>> 2.25.4
>>


Re: [PATCH 12/19] perf metric: Add events for the current list

2020-07-26 Thread kajoljain



On 7/20/20 4:04 AM, Ian Rogers wrote:
> On Sun, Jul 19, 2020 at 11:14 AM Jiri Olsa  wrote:
>>
>> There's no need to iterate the whole list of groups,
>> when adding new events. The currently created groups
>> are the ones we want to add.
>>
>> Signed-off-by: Jiri Olsa 
> 
> Acked-by: Ian Rogers 
> 

Reviewed-By : Kajol Jain

Thanks,
Kajol Jain
> Thanks,
> Ian
> 
>> ---
>>  tools/perf/util/metricgroup.c | 9 ++---
>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
>> index bb5757b9419d..332414d93f7a 100644
>> --- a/tools/perf/util/metricgroup.c
>> +++ b/tools/perf/util/metricgroup.c
>> @@ -813,6 +813,7 @@ static int metricgroup__add_metric(const char *metric, 
>> bool metric_no_group,
>>  {
>> struct pmu_event *pe;
>> struct egroup *eg;
>> +   LIST_HEAD(list);
>> int i, ret;
>> bool has_match = false;
>>
>> @@ -820,7 +821,7 @@ static int metricgroup__add_metric(const char *metric, 
>> bool metric_no_group,
>> has_match = true;
>> eg = NULL;
>>
>> -   ret = add_metric(group_list, pe, metric_no_group, );
>> +   ret = add_metric(, pe, metric_no_group, );
>> if (ret)
>> return ret;
>>
>> @@ -829,7 +830,7 @@ static int metricgroup__add_metric(const char *metric, 
>> bool metric_no_group,
>>  * included in the expression.
>>  */
>> ret = resolve_metric(eg, metric_no_group,
>> -group_list, map);
>> +, map);
>> if (ret)
>> return ret;
>> }
>> @@ -838,7 +839,7 @@ static int metricgroup__add_metric(const char *metric, 
>> bool metric_no_group,
>> if (!has_match)
>> return -EINVAL;
>>
>> -   list_for_each_entry(eg, group_list, nd) {
>> +   list_for_each_entry(eg, , nd) {
>> if (events->len > 0)
>> strbuf_addf(events, ",");
>>
>> @@ -850,6 +851,8 @@ static int metricgroup__add_metric(const char *metric, 
>> bool metric_no_group,
>>>pctx);
>> }
>> }
>> +
>> +   list_splice(, group_list);
>> return 0;
>>  }
>>
>> --
>> 2.25.4
>>


Re: [PATCH 11/19] perf metric: Compute referenced metrics

2020-07-26 Thread kajoljain



On 7/19/20 11:43 PM, Jiri Olsa wrote:
> Adding computation (expr__parse call) of referenced metric at
> the point when it needs to be resolved during the parent metric
> computation.
> 
> Once the inner metric is computed, the result is stored and
> used if there's another usage of that metric.
> 
> Acked-by: Ian Rogers 
> Signed-off-by: Jiri Olsa 

Reviewed-By : Kajol Jain

Thanks,
Kajol Jain
> ---
>  tools/perf/util/expr.c | 31 +++
>  tools/perf/util/expr.h |  3 +++
>  tools/perf/util/expr.y |  4 ++--
>  3 files changed, 36 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/perf/util/expr.c b/tools/perf/util/expr.c
> index d3997c2b4a90..a346ca590513 100644
> --- a/tools/perf/util/expr.c
> +++ b/tools/perf/util/expr.c
> @@ -112,6 +112,7 @@ int expr__add_ref(struct expr_parse_ctx *ctx, struct 
> metric_ref *ref)
>*/
>   data_ptr->ref.metric_name = ref->metric_name;
>   data_ptr->ref.metric_expr = ref->metric_expr;
> + data_ptr->ref.counted = false;
>   data_ptr->is_ref = true;
>  
>   ret = hashmap__set(>ids, name, data_ptr,
> @@ -133,6 +134,34 @@ int expr__get_id(struct expr_parse_ctx *ctx, const char 
> *id,
>   return hashmap__find(>ids, id, (void **)data) ? 0 : -1;
>  }
>  
> +int expr__resolve_id(struct expr_parse_ctx *ctx, const char *id,
> +  struct expr_id_data **datap)
> +{
> + struct expr_id_data *data;
> +
> + if (expr__get_id(ctx, id, datap) || !*datap) {
> + pr_debug("%s not found\n", id);
> + return -1;
> + }
> +
> + data = *datap;
> +
> + pr_debug2("lookup: is_ref %d, counted %d, val %f: %s\n",
> +   data->is_ref, data->ref.counted, data->val, id);
> +
> + if (data->is_ref && !data->ref.counted) {
> + data->ref.counted = true;
> + pr_debug("processing metric: %s ENTRY\n", id);
> + if (expr__parse(>val, ctx, data->ref.metric_expr, 1)) {
> + pr_debug("%s failed to count\n", id);
> + return -1;
> + }
> + pr_debug("processing metric: %s EXIT: %f\n", id, data->val);
> + }
> +
> + return 0;
> +}
> +
>  void expr__del_id(struct expr_parse_ctx *ctx, const char *id)
>  {
>   struct expr_id_data *old_val = NULL;
> @@ -173,6 +202,8 @@ __expr__parse(double *val, struct expr_parse_ctx *ctx, 
> const char *expr,
>   void *scanner;
>   int ret;
>  
> + pr_debug2("parsing metric: %s\n", expr);
> +
>   ret = expr_lex_init_extra(_ctx, );
>   if (ret)
>   return ret;
> diff --git a/tools/perf/util/expr.h b/tools/perf/util/expr.h
> index 81d04ff7f857..9ed208d93418 100644
> --- a/tools/perf/util/expr.h
> +++ b/tools/perf/util/expr.h
> @@ -23,6 +23,7 @@ struct expr_id_data {
>   struct {
>   const char *metric_name;
>   const char *metric_expr;
> + bool counted;
>   } ref;
>   };
>  
> @@ -42,6 +43,8 @@ int expr__add_id_val(struct expr_parse_ctx *ctx, const char 
> *id, double val);
>  int expr__add_ref(struct expr_parse_ctx *ctx, struct metric_ref *ref);
>  int expr__get_id(struct expr_parse_ctx *ctx, const char *id,
>struct expr_id_data **data);
> +int expr__resolve_id(struct expr_parse_ctx *ctx, const char *id,
> +  struct expr_id_data **datap);
>  int expr__parse(double *final_val, struct expr_parse_ctx *ctx,
>   const char *expr, int runtime);
>  int expr__find_other(const char *expr, const char *one,
> diff --git a/tools/perf/util/expr.y b/tools/perf/util/expr.y
> index 0d4f5d324be7..d34b370391c6 100644
> --- a/tools/perf/util/expr.y
> +++ b/tools/perf/util/expr.y
> @@ -88,11 +88,11 @@ expr:   NUMBER
>   | ID{
>   struct expr_id_data *data;
>  
> - if (expr__get_id(ctx, $1, ) || 
> !data) {
> - pr_debug("%s not found\n", $1);
> + if (expr__resolve_id(ctx, $1, )) {
>   free($1);
>   YYABORT;
>   }
> +
>   $$ = data->val;
>   free($1);
>   }
> 


Re: [PATCH 13/19] perf metric: Add cache_miss_cycles to metric parse test

2020-07-26 Thread kajoljain



On 7/19/20 11:43 PM, Jiri Olsa wrote:
> Adding test that compute metric with other metrics in it.
> 
>   cache_miss_cycles = metric:dcache_miss_cpi + metric:icache_miss_cycles
> 
> Acked-by: Ian Rogers 
> Signed-off-by: Jiri Olsa 

Reviewed-By : Kajol Jain

Thanks,
Kajol Jain
> ---
>  tools/perf/tests/parse-metric.c | 33 +
>  1 file changed, 33 insertions(+)
> 
> diff --git a/tools/perf/tests/parse-metric.c b/tools/perf/tests/parse-metric.c
> index 8c48251425e1..28f33893338b 100644
> --- a/tools/perf/tests/parse-metric.c
> +++ b/tools/perf/tests/parse-metric.c
> @@ -11,6 +11,8 @@
>  #include "debug.h"
>  #include "expr.h"
>  #include "stat.h"
> +#include 
> +#include 
>  
>  static struct pmu_event pme_test[] = {
>  {
> @@ -22,6 +24,18 @@ static struct pmu_event pme_test[] = {
> "( 1 + cpu_clk_unhalted.one_thread_active / 
> cpu_clk_unhalted.ref_xclk ) )))",
>   .metric_name= "Frontend_Bound_SMT",
>  },
> +{
> + .metric_expr= "l1d\\-loads\\-misses / inst_retired.any",
> + .metric_name= "dcache_miss_cpi",
> +},
> +{
> + .metric_expr= "l1i\\-loads\\-misses / inst_retired.any",
> + .metric_name= "icache_miss_cycles",
> +},
> +{
> + .metric_expr= "(dcache_miss_cpi + icache_miss_cycles)",
> + .metric_name= "cache_miss_cycles",
> +},
>  };
>  
>  static struct pmu_events_map map = {
> @@ -162,9 +176,28 @@ static int test_frontend(void)
>   return 0;
>  }
>  
> +static int test_cache_miss_cycles(void)
> +{
> + double ratio;
> + struct value vals[] = {
> + { .event = "l1d-loads-misses",  .val = 300 },
> + { .event = "l1i-loads-misses",  .val = 200 },
> + { .event = "inst_retired.any",  .val = 400 },
> + { 0 },
> + };
> +
> + TEST_ASSERT_VAL("failed to compute metric",
> + compute_metric("cache_miss_cycles", vals, ) == 0);
> +
> + TEST_ASSERT_VAL("cache_miss_cycles failed, wrong ratio",
> + ratio == 1.25);
> + return 0;
> +}
> +
>  int test__parse_metric(struct test *test __maybe_unused, int subtest 
> __maybe_unused)
>  {
>   TEST_ASSERT_VAL("IPC failed", test_ipc() == 0);
>   TEST_ASSERT_VAL("frontend failed", test_frontend() == 0);
> + TEST_ASSERT_VAL("cache_miss_cycles failed", test_cache_miss_cycles() == 
> 0);
>   return 0;
>  }
> 


Re: [PATCH 14/19] perf metric: Add DCache_L2 to metric parse test

2020-07-26 Thread kajoljain



On 7/19/20 11:43 PM, Jiri Olsa wrote:
> Adding test that compute DCache_L2 metrics with other related metrics in it.
> 
> Acked-by: Ian Rogers 
> Signed-off-by: Jiri Olsa 

Reviewed-By : Kajol Jain

Thanks,
Kajol Jain
> ---
>  tools/perf/tests/parse-metric.c | 71 +
>  1 file changed, 71 insertions(+)
> 
> diff --git a/tools/perf/tests/parse-metric.c b/tools/perf/tests/parse-metric.c
> index 28f33893338b..aa4d5a9f09a8 100644
> --- a/tools/perf/tests/parse-metric.c
> +++ b/tools/perf/tests/parse-metric.c
> @@ -36,6 +36,27 @@ static struct pmu_event pme_test[] = {
>   .metric_expr= "(dcache_miss_cpi + icache_miss_cycles)",
>   .metric_name= "cache_miss_cycles",
>  },
> +{
> + .metric_expr= "l2_rqsts.demand_data_rd_hit + l2_rqsts.pf_hit + 
> l2_rqsts.rfo_hit",
> + .metric_name= "DCache_L2_All_Hits",
> +},
> +{
> + .metric_expr= "max(l2_rqsts.all_demand_data_rd - 
> l2_rqsts.demand_data_rd_hit, 0) + "
> +   "l2_rqsts.pf_miss + l2_rqsts.rfo_miss",
> + .metric_name= "DCache_L2_All_Miss",
> +},
> +{
> + .metric_expr= "dcache_l2_all_hits + dcache_l2_all_miss",
> + .metric_name= "DCache_L2_All",
> +},
> +{
> + .metric_expr= "d_ratio(dcache_l2_all_hits, dcache_l2_all)",
> + .metric_name= "DCache_L2_Hits",
> +},
> +{
> + .metric_expr= "d_ratio(dcache_l2_all_miss, dcache_l2_all)",
> + .metric_name= "DCache_L2_Misses",
> +},
>  };
>  
>  static struct pmu_events_map map = {
> @@ -194,10 +215,60 @@ static int test_cache_miss_cycles(void)
>   return 0;
>  }
>  
> +
> +/*
> + * DCache_L2_All_Hits = l2_rqsts.demand_data_rd_hit + l2_rqsts.pf_hit + 
> l2_rqsts.rfo_hi
> + * DCache_L2_All_Miss = max(l2_rqsts.all_demand_data_rd - 
> l2_rqsts.demand_data_rd_hit, 0) +
> + *  l2_rqsts.pf_miss + l2_rqsts.rfo_miss
> + * DCache_L2_All  = dcache_l2_all_hits + dcache_l2_all_miss
> + * DCache_L2_Hits = d_ratio(dcache_l2_all_hits, dcache_l2_all)
> + * DCache_L2_Misses   = d_ratio(dcache_l2_all_miss, dcache_l2_all)
> + *
> + * l2_rqsts.demand_data_rd_hit = 100
> + * l2_rqsts.pf_hit = 200
> + * l2_rqsts.rfo_hi = 300
> + * l2_rqsts.all_demand_data_rd = 400
> + * l2_rqsts.pf_miss= 500
> + * l2_rqsts.rfo_miss   = 600
> + *
> + * DCache_L2_All_Hits = 600
> + * DCache_L2_All_Miss = MAX(400 - 100, 0) + 500 + 600 = 1400
> + * DCache_L2_All  = 600 + 1400  = 2000
> + * DCache_L2_Hits = 600 / 2000  = 0.3
> + * DCache_L2_Misses   = 1400 / 2000 = 0.7
> + */
> +static int test_dcache_l2(void)
> +{
> + double ratio;
> + struct value vals[] = {
> + { .event = "l2_rqsts.demand_data_rd_hit", .val = 100 },
> + { .event = "l2_rqsts.pf_hit", .val = 200 },
> + { .event = "l2_rqsts.rfo_hit",.val = 300 },
> + { .event = "l2_rqsts.all_demand_data_rd", .val = 400 },
> + { .event = "l2_rqsts.pf_miss",.val = 500 },
> + { .event = "l2_rqsts.rfo_miss",   .val = 600 },
> + { 0 },
> + };
> +
> + TEST_ASSERT_VAL("failed to compute metric",
> + compute_metric("DCache_L2_Hits", vals, ) == 0);
> +
> + TEST_ASSERT_VAL("DCache_L2_Hits failed, wrong ratio",
> + ratio == 0.3);
> +
> + TEST_ASSERT_VAL("failed to compute metric",
> + compute_metric("DCache_L2_Misses", vals, ) == 0);
> +
> + TEST_ASSERT_VAL("DCache_L2_Misses failed, wrong ratio",
> + ratio == 0.7);
> + return 0;
> +}
> +
>  int test__parse_metric(struct test *test __maybe_unused, int subtest 
> __maybe_unused)
>  {
>   TEST_ASSERT_VAL("IPC failed", test_ipc() == 0);
>   TEST_ASSERT_VAL("frontend failed", test_frontend() == 0);
>   TEST_ASSERT_VAL("cache_miss_cycles failed", test_cache_miss_cycles() == 
> 0);
> + TEST_ASSERT_VAL("DCache_L2 failed", test_dcache_l2() == 0);
>   return 0;
>  }
> 


Re: [PATCH 10/19] perf metric: Add referenced metrics to hash data

2020-07-26 Thread kajoljain



On 7/20/20 4:02 AM, Ian Rogers wrote:
> On Sun, Jul 19, 2020 at 11:14 AM Jiri Olsa  wrote:
>>
>> Adding referenced metrics to the parsing context so they
>> can be resolved during the metric processing.
>>
>> Adding expr__add_ref function to store referenced metrics
>> into parse context.
>>
>> Signed-off-by: Jiri Olsa 
> 
> Acked-by: Ian Rogers 

Reviewed-By : Kajol Jain

Thanks,
Kajol Jain
> 
> Thanks,
> Ian
> 
>> ---
>>  tools/perf/util/expr.c| 54 +++
>>  tools/perf/util/expr.h| 13 -
>>  tools/perf/util/stat-shadow.c | 20 +
>>  3 files changed, 80 insertions(+), 7 deletions(-)
>>
>> diff --git a/tools/perf/util/expr.c b/tools/perf/util/expr.c
>> index f726211f49d4..d3997c2b4a90 100644
>> --- a/tools/perf/util/expr.c
>> +++ b/tools/perf/util/expr.c
>> @@ -4,10 +4,14 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include "metricgroup.h"
>> +#include "debug.h"
>>  #include "expr.h"
>>  #include "expr-bison.h"
>>  #include "expr-flex.h"
>>  #include 
>> +#include 
>> +#include 
>>
>>  #ifdef PARSER_DEBUG
>>  extern int expr_debug;
>> @@ -63,6 +67,7 @@ int expr__add_id_val(struct expr_parse_ctx *ctx, const 
>> char *id, double val)
>> if (!data_ptr)
>> return -ENOMEM;
>> data_ptr->val = val;
>> +   data_ptr->is_ref = false;
>>
>> ret = hashmap__set(>ids, id, data_ptr,
>>(const void **)_key, (void **)_data);
>> @@ -73,6 +78,55 @@ int expr__add_id_val(struct expr_parse_ctx *ctx, const 
>> char *id, double val)
>> return ret;
>>  }
>>
>> +int expr__add_ref(struct expr_parse_ctx *ctx, struct metric_ref *ref)
>> +{
>> +   struct expr_id_data *data_ptr = NULL, *old_data = NULL;
>> +   char *old_key = NULL;
>> +   char *name, *p;
>> +   int ret;
>> +
>> +   data_ptr = zalloc(sizeof(*data_ptr));
>> +   if (!data_ptr)
>> +   return -ENOMEM;
>> +
>> +   name = strdup(ref->metric_name);
>> +   if (!name) {
>> +   free(data_ptr);
>> +   return -ENOMEM;
>> +   }
>> +
>> +   /*
>> +* The jevents tool converts all metric expressions
>> +* to lowercase, including metric references, hence
>> +* we need to add lowercase name for metric, so it's
>> +* properly found.
>> +*/
>> +   for (p = name; *p; p++)
>> +   *p = tolower(*p);
>> +
>> +   /*
>> +* Intentionally passing just const char pointers,
>> +* originally from 'struct pmu_event' object.
>> +* We don't need to change them, so there's no
>> +* need to create our own copy.
>> +*/
>> +   data_ptr->ref.metric_name = ref->metric_name;
>> +   data_ptr->ref.metric_expr = ref->metric_expr;
>> +   data_ptr->is_ref = true;
>> +
>> +   ret = hashmap__set(>ids, name, data_ptr,
>> +  (const void **)_key, (void **)_data);
>> +   if (ret)
>> +   free(data_ptr);
>> +
>> +   pr_debug2("adding ref metric %s: %s\n",
>> + ref->metric_name, ref->metric_expr);
>> +
>> +   free(old_key);
>> +   free(old_data);
>> +   return ret;
>> +}
>> +
>>  int expr__get_id(struct expr_parse_ctx *ctx, const char *id,
>>  struct expr_id_data **data)
>>  {
>> diff --git a/tools/perf/util/expr.h b/tools/perf/util/expr.h
>> index 2462abd0ac65..81d04ff7f857 100644
>> --- a/tools/perf/util/expr.h
>> +++ b/tools/perf/util/expr.h
>> @@ -11,12 +11,22 @@
>>  #include "util/hashmap.h"
>>  //#endif
>>
>> +struct metric_ref;
>> +
>>  struct expr_parse_ctx {
>> struct hashmap ids;
>>  };
>>
>>  struct expr_id_data {
>> -   double  val;
>> +   union {
>> +   double val;
>> +   struct {
>> +   const char *metric_name;
>> +   const char *metric_expr;
>> +   } ref;
>> +   };
>> +
>> +   bool is_ref;
>>  };
>>
>>  struct expr_scanner_ctx {
>> @@ -29,6 +39,7 @@ void expr__ctx_clear(struct expr_parse_ctx *ctx);
>>  void expr__del_id(struct expr_parse_ctx *ctx, const char *id);
>>  int expr__add_id(struct expr_parse_ctx *ctx, const char *id);
>>  int expr__add_id_val(struct expr_parse_ctx *ctx, const char *id, double 
>> val);
>> +int expr__add_ref(struct expr_parse_ctx *ctx, struct metric_ref *ref);
>>  int expr__get_id(struct expr_parse_ctx *ctx, const char *id,
>>  struct expr_id_data **data);
>>  int expr__parse(double *final_val, struct expr_parse_ctx *ctx,
>> diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
>> index fc9ac4b4218e..e1ba6c1b916a 100644
>> --- a/tools/perf/util/stat-shadow.c
>> +++ b/tools/perf/util/stat-shadow.c
>> @@ -731,13 +731,14 @@ static void print_smi_cost(struct perf_stat_config 
>> *config,
>>  }
>>
>>  static int prepare_metric(struct evsel **metric_events,
>> + struct metric_ref *metric_refs,
>>  

Re: [PATCH 07/19] perf metric: Rename __metricgroup__add_metric to __add_metric

2020-07-26 Thread kajoljain



On 7/19/20 11:43 PM, Jiri Olsa wrote:
> Renaming __metricgroup__add_metric to __add_metric
> to fit in the current function names.
> 
> Acked-by: Ian Rogers 
> Signed-off-by: Jiri Olsa 

Reviewed-By : Kajol Jain

Thanks,
Kajol Jain
> ---
>  tools/perf/util/metricgroup.c | 17 ++---
>  1 file changed, 6 insertions(+), 11 deletions(-)
> 
> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
> index 4096be7a7a9e..ccd80538a6ae 100644
> --- a/tools/perf/util/metricgroup.c
> +++ b/tools/perf/util/metricgroup.c
> @@ -571,10 +571,10 @@ int __weak arch_get_runtimeparam(void)
>   return 1;
>  }
>  
> -static int __metricgroup__add_metric(struct list_head *group_list,
> -  struct pmu_event *pe,
> -  bool metric_no_group,
> -  int runtime)
> +static int __add_metric(struct list_head *group_list,
> + struct pmu_event *pe,
> + bool metric_no_group,
> + int runtime)
>  {
>   struct egroup *eg;
>  
> @@ -634,10 +634,7 @@ static int add_metric(struct list_head *group_list,
>   pr_debug("metric expr %s for %s\n", pe->metric_expr, pe->metric_name);
>  
>   if (!strstr(pe->metric_expr, "?")) {
> - ret = __metricgroup__add_metric(group_list,
> - pe,
> - metric_no_group,
> - 1);
> + ret = __add_metric(group_list, pe, metric_no_group, 1);
>   } else {
>   int j, count;
>  
> @@ -649,9 +646,7 @@ static int add_metric(struct list_head *group_list,
>*/
>  
>   for (j = 0; j < count && !ret; j++) {
> - ret = __metricgroup__add_metric(
> - group_list, pe,
> - metric_no_group, j);
> + ret = __add_metric(group_list, pe, metric_no_group, j);
>   }
>   }
>  
> 


Re: [PATCH 08/19] perf metric: Collect referenced metrics in struct metric_ref_node

2020-07-26 Thread kajoljain



On 7/20/20 3:48 AM, Ian Rogers wrote:
> On Sun, Jul 19, 2020 at 11:13 AM Jiri Olsa  wrote:
>>
>> Collecting referenced metrics in struct metric_ref_node object,
>> so we can process them later on.
>>
>> The change will parse nested metric names out of expression and
>> 'resolve' them.
>>
>> All referenced metrics are dissolved into one context, meaning all
>> nested metrics events and added to the parent context.
>>
>> Signed-off-by: Jiri Olsa 
> 
> Acked-by: Ian Rogers 
> 
> Thanks,
> Ian

Reviewed-By : Kajol Jain

Thanks,
Kajol Jain
> 
>> ---
>>  tools/perf/util/metricgroup.c | 170 +++---
>>  1 file changed, 156 insertions(+), 14 deletions(-)
>>
>> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
>> index ccd80538a6ae..d1b2c1aa436f 100644
>> --- a/tools/perf/util/metricgroup.c
>> +++ b/tools/perf/util/metricgroup.c
>> @@ -102,12 +102,25 @@ void metricgroup__rblist_exit(struct rblist 
>> *metric_events)
>> rblist__exit(metric_events);
>>  }
>>
>> +/*
>> + * A node in the list of referenced metrics. metric_expr
>> + * is held as a convenience to avoid a search through the
>> + * metric list.
>> + */
>> +struct metric_ref_node {
>> +   const char *metric_name;
>> +   const char *metric_expr;
>> +   struct list_head list;
>> +};
>> +
>>  struct egroup {
>> struct list_head nd;
>> struct expr_parse_ctx pctx;
>> const char *metric_name;
>> const char *metric_expr;
>> const char *metric_unit;
>> +   struct list_head metric_refs;
>> +   int metric_refs_cnt;
>> int runtime;
>> bool has_constraint;
>>  };
>> @@ -574,27 +587,72 @@ int __weak arch_get_runtimeparam(void)
>>  static int __add_metric(struct list_head *group_list,
>> struct pmu_event *pe,
>> bool metric_no_group,
>> -   int runtime)
>> +   int runtime,
>> +   struct egroup **egp)
>>  {
>> +   struct metric_ref_node *ref;
>> struct egroup *eg;
>>
>> -   eg = malloc(sizeof(*eg));
>> -   if (!eg)
>> -   return -ENOMEM;
>> +   if (*egp == NULL) {
>> +   /*
>> +* We got in here for the parent group,
>> +* allocate it and put it on the list.
>> +*/
>> +   eg = malloc(sizeof(*eg));
>> +   if (!eg)
>> +   return -ENOMEM;
>> +
>> +   expr__ctx_init(>pctx);
>> +   eg->metric_name = pe->metric_name;
>> +   eg->metric_expr = pe->metric_expr;
>> +   eg->metric_unit = pe->unit;
>> +   eg->runtime = runtime;
>> +   eg->has_constraint = metric_no_group || 
>> metricgroup__has_constraint(pe);
>> +   INIT_LIST_HEAD(>metric_refs);
>> +   eg->metric_refs_cnt = 0;
>> +   *egp = eg;
>> +   } else {
>> +   /*
>> +* We got here for the referenced metric, via the
>> +* recursive metricgroup__add_metric call, add
>> +* it to the parent group.
>> +*/
>> +   eg = *egp;
>> +
>> +   ref = malloc(sizeof(*ref));
>> +   if (!ref)
>> +   return -ENOMEM;
>> +
>> +   /*
>> +* Intentionally passing just const char pointers,
>> +* from 'pe' object, so they never go away. We don't
>> +* need to change them, so there's no need to create
>> +* our own copy.
>> +*/
>> +   ref->metric_name = pe->metric_name;
>> +   ref->metric_expr = pe->metric_expr;
>>
>> -   expr__ctx_init(>pctx);
>> -   eg->metric_name = pe->metric_name;
>> -   eg->metric_expr = pe->metric_expr;
>> -   eg->metric_unit = pe->unit;
>> -   eg->runtime = runtime;
>> -   eg->has_constraint = metric_no_group || 
>> metricgroup__has_constraint(pe);
>> +   list_add(>list, >metric_refs);
>> +   eg->metric_refs_cnt++;
>> +   }
>>
>> +   /*
>> +* For both the parent and referenced metrics, we parse
>> +* all the metric's IDs and add it to the parent context.
>> +*/
>> if (expr__find_other(pe->metric_expr, NULL, >pctx, runtime) < 0) 
>> {
>> expr__ctx_clear(>pctx);
>> free(eg);
>> return -EINVAL;
>> }
>>
>> +   /*
>> +* We add new group only in the 'parent' call,
>> +* so bail out for referenced metric case.
>> +*/
>> +   if (eg->metric_refs_cnt)
>> +   return 0;
>> +
>> if (list_empty(group_list))
>> list_add(>nd, group_list);
>> else {
>> @@ -625,16 +683,78 @@ static int __add_metric(struct list_head *group_list,
>> (match_metric(__pe->metric_group, __metric) ||

Re: [PATCH 06/19] perf metric: Add add_metric function

2020-07-26 Thread kajoljain



On 7/19/20 11:43 PM, Jiri Olsa wrote:
> Decouple metric adding logging into add_metric function,
> so it can be used from other places in following changes.
> 
> Acked-by: Ian Rogers 
> Signed-off-by: Jiri Olsa 
> ---

Reviewed-By : Kajol Jain

Thanks,
Kajol Jain
>  tools/perf/util/metricgroup.c | 62 ---
>  1 file changed, 36 insertions(+), 26 deletions(-)
> 
> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
> index b37008fc253c..4096be7a7a9e 100644
> --- a/tools/perf/util/metricgroup.c
> +++ b/tools/perf/util/metricgroup.c
> @@ -625,6 +625,39 @@ static int __metricgroup__add_metric(struct list_head 
> *group_list,
>   (match_metric(__pe->metric_group, __metric) ||  \
>match_metric(__pe->metric_name, __metric)))
>  
> +static int add_metric(struct list_head *group_list,
> +   struct pmu_event *pe,
> +   bool metric_no_group)
> +{
> + int ret = 0;
> +
> + pr_debug("metric expr %s for %s\n", pe->metric_expr, pe->metric_name);
> +
> + if (!strstr(pe->metric_expr, "?")) {
> + ret = __metricgroup__add_metric(group_list,
> + pe,
> + metric_no_group,
> + 1);
> + } else {
> + int j, count;
> +
> + count = arch_get_runtimeparam();
> +
> + /* This loop is added to create multiple
> +  * events depend on count value and add
> +  * those events to group_list.
> +  */
> +
> + for (j = 0; j < count && !ret; j++) {
> + ret = __metricgroup__add_metric(
> + group_list, pe,
> + metric_no_group, j);
> + }
> + }
> +
> + return ret;
> +}
> +
>  static int metricgroup__add_metric(const char *metric, bool metric_no_group,
>  struct strbuf *events,
>  struct list_head *group_list,
> @@ -636,34 +669,11 @@ static int metricgroup__add_metric(const char *metric, 
> bool metric_no_group,
>   bool has_match = false;
>  
>   map_for_each_metric(pe, i, map, metric) {
> - pr_debug("metric expr %s for %s\n", pe->metric_expr, 
> pe->metric_name);
>   has_match = true;
>  
> - if (!strstr(pe->metric_expr, "?")) {
> - ret = __metricgroup__add_metric(group_list,
> - pe,
> - metric_no_group,
> - 1);
> - if (ret)
> - return ret;
> - } else {
> - int j, count;
> -
> - count = arch_get_runtimeparam();
> -
> - /* This loop is added to create multiple
> -  * events depend on count value and add
> -  * those events to group_list.
> -  */
> -
> - for (j = 0; j < count; j++) {
> - ret = __metricgroup__add_metric(
> - group_list, pe,
> - metric_no_group, j);
> - if (ret)
> - return ret;
> - }
> - }
> + ret = add_metric(group_list, pe, metric_no_group);
> + if (ret)
> + return ret;
>   }
>  
>   /* End of pmu events. */
> 


Re: [PATCH 09/19] perf metric: Collect referenced metrics in struct metric_expr

2020-07-26 Thread kajoljain



On 7/19/20 11:43 PM, Jiri Olsa wrote:
> Add referenced metrics into struct metric_expr object,
> so they are accessible when computing the metric.
> 
> Storing just name and expression itself, so the metric
> can be resolved and computed.
> 
> Acked-by: Ian Rogers 
> Signed-off-by: Jiri Olsa 

Reviewed-By : Kajol Jain

Thanks,
Kajol Jain
> ---
>  tools/perf/util/metricgroup.c | 32 
>  tools/perf/util/metricgroup.h |  6 ++
>  2 files changed, 38 insertions(+)
> 
> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
> index d1b2c1aa436f..bb5757b9419d 100644
> --- a/tools/perf/util/metricgroup.c
> +++ b/tools/perf/util/metricgroup.c
> @@ -83,6 +83,7 @@ static void metric_event_delete(struct rblist *rblist 
> __maybe_unused,
>   struct metric_expr *expr, *tmp;
>  
>   list_for_each_entry_safe(expr, tmp, >head, nd) {
> + free(expr->metric_refs);
>   free(expr);
>   }
>  
> @@ -248,6 +249,7 @@ static int metricgroup__setup_events(struct list_head 
> *groups,
>  
>   list_for_each_entry (eg, groups, nd) {
>   struct evsel **metric_events;
> + struct metric_ref *metric_refs = NULL;
>  
>   metric_events = calloc(sizeof(void *),
>   hashmap__size(>pctx.ids) + 1);
> @@ -279,6 +281,36 @@ static int metricgroup__setup_events(struct list_head 
> *groups,
>   free(metric_events);
>   break;
>   }
> +
> + /*
> +  * Collect and store collected nested expressions
> +  * for metric processing.
> +  */
> + if (eg->metric_refs_cnt) {
> + struct metric_ref_node *ref;
> +
> + metric_refs = zalloc(sizeof(struct metric_ref) * 
> (eg->metric_refs_cnt + 1));
> + if (!metric_refs) {
> + ret = -ENOMEM;
> + free(metric_events);
> + break;
> + }
> +
> + i = 0;
> + list_for_each_entry(ref, >metric_refs, list) {
> + /*
> +  * Intentionally passing just const char 
> pointers,
> +  * originally from 'struct pmu_event' object.
> +  * We don't need to change them, so there's no
> +  * need to create our own copy.
> +  */
> + metric_refs[i].metric_name = ref->metric_name;
> + metric_refs[i].metric_expr = ref->metric_expr;
> + i++;
> + }
> + };
> +
> + expr->metric_refs = metric_refs;
>   expr->metric_expr = eg->metric_expr;
>   expr->metric_name = eg->metric_name;
>   expr->metric_unit = eg->metric_unit;
> diff --git a/tools/perf/util/metricgroup.h b/tools/perf/util/metricgroup.h
> index 8315bd1a7da4..62623a39cbec 100644
> --- a/tools/perf/util/metricgroup.h
> +++ b/tools/perf/util/metricgroup.h
> @@ -18,12 +18,18 @@ struct metric_event {
>   struct list_head head; /* list of metric_expr */
>  };
>  
> +struct metric_ref {
> + const char *metric_name;
> + const char *metric_expr;
> +};
> +
>  struct metric_expr {
>   struct list_head nd;
>   const char *metric_expr;
>   const char *metric_name;
>   const char *metric_unit;
>   struct evsel **metric_events;
> + struct metric_ref *metric_refs;
>   int runtime;
>  };
>  
> 


Re: [PATCH 05/19] perf metric: Add macros for iterating map events

2020-07-26 Thread kajoljain



On 7/19/20 11:43 PM, Jiri Olsa wrote:
> Adding following macros to iterate events and metric:
>   map_for_each_event(__pe, __idx, __map)
> - iterates over all pmu_events_map events
>   map_for_each_metric(__pe, __idx, __map, __metric)
> - iterates over all metrics that match __metric argument
> 
> and use it in metricgroup__add_metric function. Macros
> will be be used from other places in following changes.
> 
> Signed-off-by: Jiri Olsa 

Reviewed-By : Kajol Jain

Thanks,
Kajol Jain

> ---
>  tools/perf/util/metricgroup.c | 77 ++-
>  1 file changed, 40 insertions(+), 37 deletions(-)
> 
> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
> index df0356ec120d..b37008fc253c 100644
> --- a/tools/perf/util/metricgroup.c
> +++ b/tools/perf/util/metricgroup.c
> @@ -614,6 +614,17 @@ static int __metricgroup__add_metric(struct list_head 
> *group_list,
>   return 0;
>  }
>  
> +#define map_for_each_event(__pe, __idx, __map)   
> \
> + for (__idx = 0, __pe = &__map->table[__idx];\
> +  __pe->name || __pe->metric_group || __pe->metric_name; \
> +  __pe = &__map->table[++__idx])
> +
> +#define map_for_each_metric(__pe, __idx, __map, __metric)\
> + map_for_each_event(__pe, __idx, __map)  \
> + if (__pe->metric_expr &&\
> + (match_metric(__pe->metric_group, __metric) ||  \
> +  match_metric(__pe->metric_name, __metric)))
> +
>  static int metricgroup__add_metric(const char *metric, bool metric_no_group,
>  struct strbuf *events,
>  struct list_head *group_list,
> @@ -624,49 +635,41 @@ static int metricgroup__add_metric(const char *metric, 
> bool metric_no_group,
>   int i, ret;
>   bool has_match = false;
>  
> - for (i = 0; ; i++) {
> - pe = >table[i];
> -
> - if (!pe->name && !pe->metric_group && !pe->metric_name) {
> - /* End of pmu events. */
> - if (!has_match)
> - return -EINVAL;
> - break;
> - }
> - if (!pe->metric_expr)
> - continue;
> - if (match_metric(pe->metric_group, metric) ||
> - match_metric(pe->metric_name, metric)) {
> - has_match = true;
> - pr_debug("metric expr %s for %s\n", pe->metric_expr, 
> pe->metric_name);
> -
> - if (!strstr(pe->metric_expr, "?")) {
> - ret = __metricgroup__add_metric(group_list,
> - pe,
> - metric_no_group,
> - 1);
> - if (ret)
> - return ret;
> - } else {
> - int j, count;
> + map_for_each_metric(pe, i, map, metric) {
> + pr_debug("metric expr %s for %s\n", pe->metric_expr, 
> pe->metric_name);
> + has_match = true;
> +
> + if (!strstr(pe->metric_expr, "?")) {
> + ret = __metricgroup__add_metric(group_list,
> + pe,
> + metric_no_group,
> + 1);
> + if (ret)
> + return ret;
> + } else {
> + int j, count;
>  
> - count = arch_get_runtimeparam();
> + count = arch_get_runtimeparam();
>  
> - /* This loop is added to create multiple
> -  * events depend on count value and add
> -  * those events to group_list.
> -  */
> + /* This loop is added to create multiple
> +  * events depend on count value and add
> +  * those events to group_list.
> +  */
>  
> - for (j = 0; j < count; j++) {
> - ret = __metricgroup__add_metric(
> - group_list, pe,
> - metric_no_group, j);
> - if (ret)
> - return ret;
> - }
> + for (j = 0; j < count; j++) {
> + ret = __metricgroup__add_metric(
> + group_list, pe,
> + 

Re: [PATCH 04/19] perf metric: Add expr__del_id function

2020-07-26 Thread kajoljain



On 7/19/20 11:43 PM, Jiri Olsa wrote:
> Adding expr__del_id function to remove ID from hashmap.
> It will save us few lines in following changes.
> 
> Acked-by: Ian Rogers 
> Signed-off-by: Jiri Olsa 

Reviewed-By : Kajol Jain

Thanks,
Kajol Jain

> ---
>  tools/perf/util/expr.c | 21 +
>  tools/perf/util/expr.h |  1 +
>  2 files changed, 14 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/perf/util/expr.c b/tools/perf/util/expr.c
> index 4e5a6533dfce..f726211f49d4 100644
> --- a/tools/perf/util/expr.c
> +++ b/tools/perf/util/expr.c
> @@ -79,6 +79,17 @@ int expr__get_id(struct expr_parse_ctx *ctx, const char 
> *id,
>   return hashmap__find(>ids, id, (void **)data) ? 0 : -1;
>  }
>  
> +void expr__del_id(struct expr_parse_ctx *ctx, const char *id)
> +{
> + struct expr_id_data *old_val = NULL;
> + char *old_key = NULL;
> +
> + hashmap__delete(>ids, id,
> + (const void **)_key, (void **)_val);
> + free(old_key);
> + free(old_val);
> +}
> +
>  void expr__ctx_init(struct expr_parse_ctx *ctx)
>  {
>   hashmap__init(>ids, key_hash, key_equal, NULL);
> @@ -136,16 +147,10 @@ int expr__parse(double *final_val, struct 
> expr_parse_ctx *ctx,
>  int expr__find_other(const char *expr, const char *one,
>struct expr_parse_ctx *ctx, int runtime)
>  {
> - struct expr_id_data *old_val = NULL;
> - char *old_key = NULL;
>   int ret = __expr__parse(NULL, ctx, expr, EXPR_OTHER, runtime);
>  
> - if (one) {
> - hashmap__delete(>ids, one,
> - (const void **)_key, (void **)_val);
> - free(old_key);
> - free(old_val);
> - }
> + if (one)
> + expr__del_id(ctx, one);
>  
>   return ret;
>  }
> diff --git a/tools/perf/util/expr.h b/tools/perf/util/expr.h
> index f38292fdab19..2462abd0ac65 100644
> --- a/tools/perf/util/expr.h
> +++ b/tools/perf/util/expr.h
> @@ -26,6 +26,7 @@ struct expr_scanner_ctx {
>  
>  void expr__ctx_init(struct expr_parse_ctx *ctx);
>  void expr__ctx_clear(struct expr_parse_ctx *ctx);
> +void expr__del_id(struct expr_parse_ctx *ctx, const char *id);
>  int expr__add_id(struct expr_parse_ctx *ctx, const char *id);
>  int expr__add_id_val(struct expr_parse_ctx *ctx, const char *id, double val);
>  int expr__get_id(struct expr_parse_ctx *ctx, const char *id,
> 


Re: [PATCH 02/19] perf metric: Add expr__add_id function

2020-07-26 Thread kajoljain



On 7/19/20 11:43 PM, Jiri Olsa wrote:
> Adding expr__add_id function to data for ID
> with zero value, which is used when scanning
> the expression for IDs.
> 

Reviewed-By : Kajol Jain

Thanks,
Kajol Jain

> Acked-by: Ian Rogers 
> Signed-off-by: Jiri Olsa 
> ---
>  tools/perf/util/expr.c | 31 +--
>  tools/perf/util/expr.h |  1 +
>  tools/perf/util/expr.y |  2 +-
>  3 files changed, 27 insertions(+), 7 deletions(-)
> 
> diff --git a/tools/perf/util/expr.c b/tools/perf/util/expr.c
> index 578a173d4873..9228f60e2a20 100644
> --- a/tools/perf/util/expr.c
> +++ b/tools/perf/util/expr.c
> @@ -32,6 +32,26 @@ static bool key_equal(const void *key1, const void *key2,
>   return !strcmp((const char *)key1, (const char *)key2);
>  }
>  
> +/* Caller must make sure id is allocated */
> +int expr__add_id(struct expr_parse_ctx *ctx, const char *id)
> +{
> + struct expr_id_data *data_ptr = NULL, *old_data = NULL;
> + char *old_key = NULL;
> + int ret;
> +
> + data_ptr = malloc(sizeof(*data_ptr));
> + if (!data_ptr)
> + return -ENOMEM;
> +
> + ret = hashmap__set(>ids, id, data_ptr,
> +(const void **)_key, (void **)_data);
> + if (ret)
> + free(data_ptr);
> + free(old_key);
> + free(old_data);
> + return ret;
> +}
> +
>  /* Caller must make sure id is allocated */
>  int expr__add_id_val(struct expr_parse_ctx *ctx, const char *id, double val)
>  {
> @@ -39,12 +59,11 @@ int expr__add_id_val(struct expr_parse_ctx *ctx, const 
> char *id, double val)
>   char *old_key = NULL;
>   int ret;
>  
> - if (val != 0.0) {
> - data_ptr = malloc(sizeof(*data_ptr));
> - if (!data_ptr)
> - return -ENOMEM;
> - data_ptr->val = val;
> - }
> + data_ptr = malloc(sizeof(*data_ptr));
> + if (!data_ptr)
> + return -ENOMEM;
> + data_ptr->val = val;
> +
>   ret = hashmap__set(>ids, id, data_ptr,
>  (const void **)_key, (void **)_data);
>   if (ret)
> diff --git a/tools/perf/util/expr.h b/tools/perf/util/expr.h
> index 21fe5bd85718..ac32cda42006 100644
> --- a/tools/perf/util/expr.h
> +++ b/tools/perf/util/expr.h
> @@ -26,6 +26,7 @@ struct expr_scanner_ctx {
>  
>  void expr__ctx_init(struct expr_parse_ctx *ctx);
>  void expr__ctx_clear(struct expr_parse_ctx *ctx);
> +int expr__add_id(struct expr_parse_ctx *ctx, const char *id);
>  int expr__add_id_val(struct expr_parse_ctx *ctx, const char *id, double val);
>  int expr__get_id(struct expr_parse_ctx *ctx, const char *id, double 
> *val_ptr);
>  int expr__parse(double *final_val, struct expr_parse_ctx *ctx,
> diff --git a/tools/perf/util/expr.y b/tools/perf/util/expr.y
> index b2b3420ea6ec..8befe4a46f87 100644
> --- a/tools/perf/util/expr.y
> +++ b/tools/perf/util/expr.y
> @@ -69,7 +69,7 @@ all_other: all_other other
>  
>  other: ID
>  {
> - expr__add_id_val(ctx, $1, 0.0);
> + expr__add_id(ctx, $1);
>  }
>  |
>  MIN | MAX | IF | ELSE | SMT_ON | NUMBER | '|' | '^' | '&' | '-' | '+' | '*' 
> | '/' | '%' | '(' | ')' | ','
> 


Re: [PATCH 03/19] perf metric: Change expr__get_id to return struct expr_id_data

2020-07-26 Thread kajoljain



On 7/19/20 11:43 PM, Jiri Olsa wrote:
> Changing expr__get_id to use and return struct expr_id_data
> pointer as value for the ID. This way we can access data other
> than value for given ID in following changes.
> 
> Acked-by: Ian Rogers 
> Signed-off-by: Jiri Olsa 
> ---

Reviewed-By : Kajol Jain

Thanks,
Kajol Jain

>  tools/perf/util/expr.c | 10 +++---
>  tools/perf/util/expr.h |  3 ++-
>  tools/perf/util/expr.y | 14 +-
>  3 files changed, 14 insertions(+), 13 deletions(-)
> 
> diff --git a/tools/perf/util/expr.c b/tools/perf/util/expr.c
> index 9228f60e2a20..4e5a6533dfce 100644
> --- a/tools/perf/util/expr.c
> +++ b/tools/perf/util/expr.c
> @@ -73,14 +73,10 @@ int expr__add_id_val(struct expr_parse_ctx *ctx, const 
> char *id, double val)
>   return ret;
>  }
>  
> -int expr__get_id(struct expr_parse_ctx *ctx, const char *id, double *val_ptr)
> +int expr__get_id(struct expr_parse_ctx *ctx, const char *id,
> +  struct expr_id_data **data)
>  {
> - struct expr_id_data *data;
> -
> - if (!hashmap__find(>ids, id, (void **)))
> - return -1;
> - *val_ptr = (data == NULL) ?  0.0 : data->val;
> - return 0;
> + return hashmap__find(>ids, id, (void **)data) ? 0 : -1;
>  }
>  
>  void expr__ctx_init(struct expr_parse_ctx *ctx)
> diff --git a/tools/perf/util/expr.h b/tools/perf/util/expr.h
> index ac32cda42006..f38292fdab19 100644
> --- a/tools/perf/util/expr.h
> +++ b/tools/perf/util/expr.h
> @@ -28,7 +28,8 @@ void expr__ctx_init(struct expr_parse_ctx *ctx);
>  void expr__ctx_clear(struct expr_parse_ctx *ctx);
>  int expr__add_id(struct expr_parse_ctx *ctx, const char *id);
>  int expr__add_id_val(struct expr_parse_ctx *ctx, const char *id, double val);
> -int expr__get_id(struct expr_parse_ctx *ctx, const char *id, double 
> *val_ptr);
> +int expr__get_id(struct expr_parse_ctx *ctx, const char *id,
> +  struct expr_id_data **data);
>  int expr__parse(double *final_val, struct expr_parse_ctx *ctx,
>   const char *expr, int runtime);
>  int expr__find_other(const char *expr, const char *one,
> diff --git a/tools/perf/util/expr.y b/tools/perf/util/expr.y
> index 8befe4a46f87..0d4f5d324be7 100644
> --- a/tools/perf/util/expr.y
> +++ b/tools/perf/util/expr.y
> @@ -85,12 +85,16 @@ if_expr:
>   ;
>  
>  expr:  NUMBER
> - | ID{ if (expr__get_id(ctx, $1, &$$)) {
> - pr_debug("%s not found\n", $1);
> + | ID{
> + struct expr_id_data *data;
> +
> + if (expr__get_id(ctx, $1, ) || 
> !data) {
> + pr_debug("%s not found\n", $1);
> + free($1);
> + YYABORT;
> + }
> + $$ = data->val;
>   free($1);
> - YYABORT;
> -   }
> -   free($1);
>   }
>   | expr '|' expr { $$ = (long)$1 | (long)$3; }
>   | expr '&' expr { $$ = (long)$1 & (long)$3; }
> 


Re: [PATCHv3 00/19] perf metric: Add support to reuse metric

2020-07-26 Thread kajoljain



On 7/25/20 5:21 PM, Jiri Olsa wrote:
> On Fri, Jul 24, 2020 at 11:22:28AM +0530, kajoljain wrote:
> 
> SNIP
> 
>>
>> Hi Jiri,
>>The change looks good to me. I tried with adding this patch on top of 
>> your perf/metric branch. It did resolve the issue of not printing
>> all chips data. And now I can see proper values for hv-24x7 metric events.
>>
>> I was also trying by adding new metric using the feature added in this 
>> patchset with something like this:
>>
>> diff --git a/tools/perf/pmu-events/arch/powerpc/power9/nest_metrics.json 
>> b/tools/perf/pmu-events/arch/powerpc/power9/nest_metrics.json
>> index 8383a37647ad..dfe4bd63b587 100644
>> --- a/tools/perf/pmu-events/arch/powerpc/power9/nest_metrics.json
>> +++ b/tools/perf/pmu-events/arch/powerpc/power9/nest_metrics.json
>> @@ -16,6 +16,11 @@
>>  "MetricName": "PowerBUS_Frequency",
>>  "ScaleUnit": "2.5e-7GHz"
>>  },
>> +{
>> +   "MetricExpr": "Memory_WR_BW_Chip + Memory_RD_BW_Chip",
>> +"MetricName": "Total_Memory_BW",
>> +"ScaleUnit": "1.6e-2MB"
>> +},
> 
> hum, we'll need special case this.. because Memory_WR_BW_Chip will
> unwind to Memory_WR_BW_Chip_[01] and Total_Memory_BW is not aware of
> that.. what's the expected behaviour in here?
> 
> have Total_Memory_BW_[01] for each runtime arg?

Hi Jiri,
Yes right. So we want Total_Memory_BW to show sum results of both chip 0 
and 1 seperately, which is missing here.
> 
> I think this will need to come on top of this changes,
> it's already too big
> 

Yes make sense. We can send separate patches on top of this patch set for this 
use case. 

Other then that the whole patchset looks good to me with the change to rectify 
Paul A. Clarke concern.

Tested/Reviewed-By : Kajol Jain

Thanks,
Kajol Jain
> thanks,
> jirka
> 
>>
>> I guess as we have dependency on '?' symbol, I am not able to see all chips 
>> data for Total_Memory_BW.
>> I am not sure if Its expected behavior?
>>
>> This is what I am getting:
>>
>> [root@ltc-zz189-lp4 perf]# ./perf stat --metric-only -M 
>> Total_Memory_BW,Memory_WR_BW_Chip,Memory_RD_BW_Chip -I 1000 -C 0
>> #   time  MB  Total_Memory_BW MB  Memory_RD_BW_Chip_1 MB  
>> Memory_WR_BW_Chip_1 MB  Memory_WR_BW_Chip_0 MB  Memory_RD_BW_Chip_0 
>>  1.67388 36.4  0.2   
>>   36.3 65.0 72.1 
>>  2.000374276 36.2  0.3   
>>   35.9 65.4 77.9 
>>  3.000543202 36.3  0.3   
>>   36.0 68.7 81.2 
>>  4.000702855 36.3  0.3   
>>   36.0 70.9 93.3 
>>  5.000856837 36.0  0.2   
>>   35.8 67.4 81.5 
>> ^C 5.367865273 13.2  0.1 
>> 13.1 23.5 28.3 
>>  Performance counter stats for 'CPU(s) 0':
>>194.4  1.3193.1   
>>  361.0434.3 
>>5.368039176 seconds time elapsed
>>
>> We can only get single chip data's sum in Total_Memory_BW. Please let me 
>> know if I am missing something.
> 
> SNIP
> 


Re: [PATCHv3 00/19] perf metric: Add support to reuse metric

2020-07-23 Thread kajoljain



On 7/21/20 12:46 AM, Jiri Olsa wrote:
> On Mon, Jul 20, 2020 at 02:32:40PM +0530, kajoljain wrote:
>>
>>
>> On 7/20/20 1:49 PM, Jiri Olsa wrote:
>>> On Mon, Jul 20, 2020 at 01:39:24PM +0530, kajoljain wrote:
>>>
>>> SNIP
>>>
>>>> This is with your perf/metric branch:
>>>> command# ./perf stat -M PowerBUS_Frequency -C 0 -I 1000
>>>> assertion failed at util/metricgroup.c:709
>>>> #   time counts unit events
>>>>  1.54545  7,807,505  hv_24x7/pm_pb_cyc,chip=0/ #  
>>>> 2.0 GHz  PowerBUS_Frequency_0
>>>>  1.54545  7,807,485  hv_24x7/pm_pb_cyc,chip=1/ 
>>>>   
>>>>  2.000232761  7,807,500  hv_24x7/pm_pb_cyc,chip=0/ #  
>>>> 2.0 GHz  PowerBUS_Frequency_0
>>>>  2.000232761  7,807,478  hv_24x7/pm_pb_cyc,chip=1/ 
>>>>   
>>>>  3.000363762  7,799,665  hv_24x7/pm_pb_cyc,chip=0/ #  
>>>> 1.9 GHz  PowerBUS_Frequency_0
>>>>  3.000363762  7,807,502  hv_24x7/pm_pb_cyc,chip=1/ 
>>>>   
>>>> ^C 3.259418599  2,022,150  hv_24x7/pm_pb_cyc,chip=0/ # 
>>>>  0.5 GHz  PowerBUS_Frequency_0
>>>>  3.259418599  2,022,164  hv_24x7/pm_pb_cyc,chip=1/ 
>>>>   
>>>>
>>>>  Performance counter stats for 'CPU(s) 0':
>>>>
>>>> 25,436,820  hv_24x7/pm_pb_cyc,chip=0/ #  6.4 GHz  
>>>> PowerBUS_Frequency_0
>>>> 25,444,629  hv_24x7/pm_pb_cyc,chip=1/  
>>>>  
>>>>
>>>>3.259505529 seconds time elapsed
>>>
>>> I found the bug, we are not adding runtime metrics as standalone ones,
>>> but as referenced metrics.. will fix and try to add test for that
>>>
>>> as for testing.. do I need some special ppc server to have support for 
>>> this? 
>>
>> Hi jiri,
>> We need power9 lpar machine and need to make sure `CONFIG_HV_PERF_CTRS` 
>> is
>> enabled.
> 
> could you please try with following patch on top?

Hi Jiri,
   The change looks good to me. I tried with adding this patch on top of 
your perf/metric branch. It did resolve the issue of not printing
all chips data. And now I can see proper values for hv-24x7 metric events.

I was also trying by adding new metric using the feature added in this patchset 
with something like this:

diff --git a/tools/perf/pmu-events/arch/powerpc/power9/nest_metrics.json 
b/tools/perf/pmu-events/arch/powerpc/power9/nest_metrics.json
index 8383a37647ad..dfe4bd63b587 100644
--- a/tools/perf/pmu-events/arch/powerpc/power9/nest_metrics.json
+++ b/tools/perf/pmu-events/arch/powerpc/power9/nest_metrics.json
@@ -16,6 +16,11 @@
 "MetricName": "PowerBUS_Frequency",
 "ScaleUnit": "2.5e-7GHz"
 },
+{
+   "MetricExpr": "Memory_WR_BW_Chip + Memory_RD_BW_Chip",
+"MetricName": "Total_Memory_BW",
+"ScaleUnit": "1.6e-2MB"
+},

I guess as we have dependency on '?' symbol, I am not able to see all chips 
data for Total_Memory_BW.
I am not sure if Its expected behavior?

This is what I am getting:

[root@ltc-zz189-lp4 perf]# ./perf stat --metric-only -M 
Total_Memory_BW,Memory_WR_BW_Chip,Memory_RD_BW_Chip -I 1000 -C 0
#   time  MB  Total_Memory_BW MB  Memory_RD_BW_Chip_1 MB  
Memory_WR_BW_Chip_1 MB  Memory_WR_BW_Chip_0 MB  Memory_RD_BW_Chip_0 
 1.67388 36.4  0.2  
   36.3 65.0 72.1 
 2.000374276 36.2  0.3  
   35.9 65.4 77.9 
 3.000543202 36.3  0.3  
   36.0 68.7 81.2 
 4.000702855 36.3  0.3  
   36.0 70.9 93.3 
 5.000856837 36.0  0.2  
   35.8 67.4 81.5 
^C 5.367865273 13.2  0.1
 13.1 23.5 28.3 
 Performance counter stats for 'CPU(s) 0':
   194.4  1.3193.1  
  361.0434.3 

Re: [PATCHv3 00/19] perf metric: Add support to reuse metric

2020-07-20 Thread kajoljain



On 7/20/20 1:49 PM, Jiri Olsa wrote:
> On Mon, Jul 20, 2020 at 01:39:24PM +0530, kajoljain wrote:
> 
> SNIP
> 
>> This is with your perf/metric branch:
>> command# ./perf stat -M PowerBUS_Frequency -C 0 -I 1000
>> assertion failed at util/metricgroup.c:709
>> #   time counts unit events
>>  1.54545  7,807,505  hv_24x7/pm_pb_cyc,chip=0/ #  
>> 2.0 GHz  PowerBUS_Frequency_0
>>  1.54545  7,807,485  hv_24x7/pm_pb_cyc,chip=1/   
>> 
>>  2.000232761  7,807,500  hv_24x7/pm_pb_cyc,chip=0/ #  
>> 2.0 GHz  PowerBUS_Frequency_0
>>  2.000232761  7,807,478  hv_24x7/pm_pb_cyc,chip=1/   
>> 
>>  3.000363762  7,799,665  hv_24x7/pm_pb_cyc,chip=0/ #  
>> 1.9 GHz  PowerBUS_Frequency_0
>>  3.000363762  7,807,502  hv_24x7/pm_pb_cyc,chip=1/   
>> 
>> ^C 3.259418599  2,022,150  hv_24x7/pm_pb_cyc,chip=0/ #  
>> 0.5 GHz  PowerBUS_Frequency_0
>>  3.259418599  2,022,164  hv_24x7/pm_pb_cyc,chip=1/   
>> 
>>
>>  Performance counter stats for 'CPU(s) 0':
>>
>> 25,436,820  hv_24x7/pm_pb_cyc,chip=0/ #  6.4 GHz  
>> PowerBUS_Frequency_0
>> 25,444,629  hv_24x7/pm_pb_cyc,chip=1/
>>
>>
>>3.259505529 seconds time elapsed
> 
> I found the bug, we are not adding runtime metrics as standalone ones,
> but as referenced metrics.. will fix and try to add test for that
> 
> as for testing.. do I need some special ppc server to have support for this? 

Hi jiri,
We need power9 lpar machine and need to make sure `CONFIG_HV_PERF_CTRS` is
enabled.

Thanks,
Kajol Jain
> 
> thanks,
> jirka
> 


Re: [PATCHv3 00/19] perf metric: Add support to reuse metric

2020-07-20 Thread kajoljain



On 7/20/20 12:52 PM, Jiri Olsa wrote:
> On Mon, Jul 20, 2020 at 12:14:00PM +0530, kajoljain wrote:
>>
>>
>> On 7/19/20 11:43 PM, Jiri Olsa wrote:
>>> hi,
>>> this patchset is adding the support to reused metric in
>>> another metric.
>>>
>>> For example, to define IPC by using CPI with change like:
>>>
>>>  {
>>>  "BriefDescription": "Instructions Per Cycle (per Logical 
>>> Processor)",
>>> -"MetricExpr": "INST_RETIRED.ANY / CPU_CLK_UNHALTED.THREAD",
>>> +"MetricExpr": "1/CPI",
>>>  "MetricGroup": "TopDownL1",
>>>  "MetricName": "IPC"
>>>  },
>>>
>>> I won't be able to find all the possible places we could
>>> use this at, so I wonder you guys (who was asking for this)
>>> would try it and come up with comments if there's something
>>> missing or we could already use it at some places.
>>>
>>> It's based on Arnaldo's tmp.perf/core.
>>>
>>> v3 changes:
>>>   - added some acks
>>>   - some patches got merged
>>>   - added missing zalloc include [John Garry]
>>>   - added ids array outside the egroup object [Ian]
>>>   - removed wrong m->has_constraint assignment [Ian]
>>>   - renamed 'list' to 'metric_list' [Ian]
>>>   - fixed group metric and added test for it [Paul A. Clarke]
>>>   - fixed memory leak [Arnaldo]
>>>   - using lowercase keys for metrics in hashmap, because jevents
>>> converts metric_expr to lowercase
>>>
>>> Also available in here:
>>>   git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
>>>   perf/metric
>>>
>>
>> Hi Jiri,
>>I am trying to review these patches and also test it in power box. I am 
>> testing your `perf/metric` branch.
>> With your current patches,some of hv-24x7 events not giving appropriate 
>> result
>> while doing "--metric-only" command. I can't see corresponding output for 
>> all chips.
> 
> hi,
> is that just for --metric-only option?

Hi Jiri,
   So basically, this issue is for both with/without metric-only option. 
Without metric-only option,
I am not able to see aggregate result for other chips.

This is with upstream kernel:

command# ./perf stat -M PowerBUS_Frequency -C 0 -I 1000
#   time counts unit events
 1.76370  7,807,494  hv_24x7/pm_pb_cyc,chip=0/ #  2.0 
GHz  PowerBUS_Frequency_0
 1.76370  7,807,456  hv_24x7/pm_pb_cyc,chip=1/ #  2.0 
GHz  PowerBUS_Frequency_1
 2.000259226  7,807,490  hv_24x7/pm_pb_cyc,chip=0/ #  2.0 
GHz  PowerBUS_Frequency_0
 2.000259226  7,799,691  hv_24x7/pm_pb_cyc,chip=1/ #  1.9 
GHz  PowerBUS_Frequency_1
^C 2.745238246  5,816,562  hv_24x7/pm_pb_cyc,chip=0/ #  1.5 
GHz  PowerBUS_Frequency_0
 2.745238246  5,816,580  hv_24x7/pm_pb_cyc,chip=1/ #  1.5 
GHz  PowerBUS_Frequency_1

 Performance counter stats for 'CPU(s) 0':

21,431,546  hv_24x7/pm_pb_cyc,chip=0/ #  5.4 GHz  
PowerBUS_Frequency_0
21,423,727  hv_24x7/pm_pb_cyc,chip=1/ #  5.4 GHz  
PowerBUS_Frequency_1

This is with your perf/metric branch:
command# ./perf stat -M PowerBUS_Frequency -C 0 -I 1000
assertion failed at util/metricgroup.c:709
#   time counts unit events
 1.54545  7,807,505  hv_24x7/pm_pb_cyc,chip=0/ #  2.0 
GHz  PowerBUS_Frequency_0
 1.54545  7,807,485  hv_24x7/pm_pb_cyc,chip=1/  
 
 2.000232761  7,807,500  hv_24x7/pm_pb_cyc,chip=0/ #  2.0 
GHz  PowerBUS_Frequency_0
 2.000232761  7,807,478  hv_24x7/pm_pb_cyc,chip=1/  
 
 3.000363762  7,799,665  hv_24x7/pm_pb_cyc,chip=0/ #  1.9 
GHz  PowerBUS_Frequency_0
 3.000363762  7,807,502  hv_24x7/pm_pb_cyc,chip=1/  
 
^C 3.259418599  2,022,150  hv_24x7/pm_pb_cyc,chip=0/ #  0.5 
GHz  PowerBUS_Frequency_0
 3.259418599  2,022,164  hv_24x7/pm_pb_cyc,chip=1/  
 

 Performance counter stats for 'CPU(s) 0':

25,436,820  hv_24x7/pm_pb_cyc,chip=0/ #  6.4 GHz  
PowerBUS_Frequency_0
25,444,629  hv_24x7/pm_pb_cyc,chip=1/   


   3.259505529 seconds time elapsed
Thanks,
Kajol Jain
> 
>>
>> This is output on power9 machine:
>>
>> Without your patches on upstream kernel:
>>
>>

Re: [PATCHv3 00/19] perf metric: Add support to reuse metric

2020-07-20 Thread kajoljain



On 7/19/20 11:43 PM, Jiri Olsa wrote:
> hi,
> this patchset is adding the support to reused metric in
> another metric.
> 
> For example, to define IPC by using CPI with change like:
> 
>  {
>  "BriefDescription": "Instructions Per Cycle (per Logical Processor)",
> -"MetricExpr": "INST_RETIRED.ANY / CPU_CLK_UNHALTED.THREAD",
> +"MetricExpr": "1/CPI",
>  "MetricGroup": "TopDownL1",
>  "MetricName": "IPC"
>  },
> 
> I won't be able to find all the possible places we could
> use this at, so I wonder you guys (who was asking for this)
> would try it and come up with comments if there's something
> missing or we could already use it at some places.
> 
> It's based on Arnaldo's tmp.perf/core.
> 
> v3 changes:
>   - added some acks
>   - some patches got merged
>   - added missing zalloc include [John Garry]
>   - added ids array outside the egroup object [Ian]
>   - removed wrong m->has_constraint assignment [Ian]
>   - renamed 'list' to 'metric_list' [Ian]
>   - fixed group metric and added test for it [Paul A. Clarke]
>   - fixed memory leak [Arnaldo]
>   - using lowercase keys for metrics in hashmap, because jevents
> converts metric_expr to lowercase
> 
> Also available in here:
>   git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
>   perf/metric
> 

Hi Jiri,
   I am trying to review these patches and also test it in power box. I am 
testing your `perf/metric` branch.
With your current patches,some of hv-24x7 events not giving appropriate result
while doing "--metric-only" command. I can't see corresponding output for all 
chips.

This is output on power9 machine:

Without your patches on upstream kernel:

command# ./perf stat --metric-only -M PowerBUS_Frequency -I 1000 -C 0
#   time GHz  PowerBUS_Frequency_0 GHz  PowerBUS_Frequency_1 
 1.738772.02.0 
 2.0002405512.01.9 
^C 2.4525905320.90.9 

 Performance counter stats for 'CPU(s) 0':

   4.84.8 

   2.452654834 seconds time elapsed

With your patches on perf/metric branch:

command# ./perf stat --metric-only -M PowerBUS_Frequency -I 1000 -C 0
assertion failed at util/metricgroup.c:709
#   time GHz  PowerBUS_Frequency_0 
 1.738752.0 
 2.0003807062.0 
^C 2.6589621821.3 

 Performance counter stats for 'CPU(s) 0':

   5.2 

Please let me know, if I am missing something. 

Thanks,
Kajol Jain

> thanks,
> jirka
> 
> 
> ---
> Jiri Olsa (19):
>   perf metric: Fix memory leak in expr__add_id function
>   perf metric: Add expr__add_id function
>   perf metric: Change expr__get_id to return struct expr_id_data
>   perf metric: Add expr__del_id function
>   perf metric: Add macros for iterating map events
>   perf metric: Add add_metric function
>   perf metric: Rename __metricgroup__add_metric to __add_metric
>   perf metric: Collect referenced metrics in struct metric_ref_node
>   perf metric: Collect referenced metrics in struct metric_expr
>   perf metric: Add referenced metrics to hash data
>   perf metric: Compute referenced metrics
>   perf metric: Add events for the current list
>   perf metric: Add cache_miss_cycles to metric parse test
>   perf metric: Add DCache_L2 to metric parse test
>   perf metric: Add recursion check when processing nested metrics
>   perf metric: Make compute_single function more precise
>   perf metric: Add metric group test
>   perf metric: Rename struct egroup to metric
>   perf metric: Rename group_list to metric_list
> 
>  tools/perf/tests/parse-metric.c | 206 
> +
>  tools/perf/util/expr.c  | 143 -
>  tools/perf/util/expr.h  |  30 +++-
>  tools/perf/util/expr.y  |  16 +++--
>  tools/perf/util/metricgroup.c   | 466 
> +++
>  tools/perf/util/metricgroup.h   |   6 ++
>  tools/perf/util/stat-shadow.c   |  20 --
>  7 files changed, 751 insertions(+), 136 deletions(-)
> 


Re: [PATCH v3 0/5] powerpc/perf: Add json file support for hv_24x7 core level events

2020-07-17 Thread kajoljain



On 7/16/20 8:52 PM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jul 16, 2020 at 03:12:11PM +0530, Kajol Jain escreveu:
>> Patchset enhance current runtime parameter support. It introduces new
>> fields like "PerChip" and "PerCore" similar to the field "PerPkg" which is
>> used to specify perpkg events. 
>>
>> The "PerCore" and "PerChip" specifies whether its core or chip events.
>> Based on which we can decide which runtime parameter user want to
>> access. Now character  '?' can refers different parameter based on user
>> requirement.
>>
>> Initially, every time we want to add new terms like chip, core, thread
>> etc, we need to create corrsponding fields in pmu_events and event
>> struct.
>> This patchset adds an enum called 'aggr_mode_class' which store all these
>> aggregation like perpkg/percore. It also adds new field 'AggregationMode'
>> to capture these terms.
>> Now, if user wants to add any new term, they just need to add it in
>> the enum defined. I try to test it with  my current setup.
>>
>> I also need to replace PerPkg field to AggregationMode in all the
>> x86 uncore json files. It will great if Andi and team can test it
>> and let me know if they have any concerns.
>>
>> Changelog:
>> v2 -> v3:
>> - Did some nits changes suggested by Jiri include correction of
>>   indentation, and making PerCore/PerChip values forward after
>>   PerPkg as 1 in the enum.
>> - Rebase the patchset on Arnaldo's tmp.perf/core branch.
>> - Change RFC tag
> 
> Hey, have anybody provided Acked-by/Reviewed-by for previous revisions
> of this patchset? If so you could have collected them for patches
> without changes, was that the case?

Hi Arnaldo,
  I did get "Acked-by: Ian Rogers" on my initial prototype which I send in 
my RFC.
Link to the patch: https://lkml.org/lkml/2020/7/5/399

After that, I break it down and made some nits changes as suggested by Jiri, 
that's why I didn't
add his Acked-by tag.
Ian should I add it, if it seems fine to you.

Thanks,
Kajol Jain
> 
> - Arnaldo
>  
>> v1 -> v2:
>> - Rather then adding new field as PerCore/PerChip, created a new enum
>>   to get these fields. And new field as "AggregationMode" which can
>>   be used to capture these fields from json file.
>>   - Suggested By Ian Rogers
>>
>>
>> Kajol Jain (5):
>>   perf/pmu-events/jevents: Add enum to store aggregation like PerPkg
>>   pmu-events/x86/uncore: Replace PerPkg field to AggregationMode in x86
>> json files
>>   perf jevents: Add support for parsing perchip/percore events
>>   perf/tools: Pass pmu_event structure as a parameter for
>> arch_get_runtimeparam
>>   perf/tools/pmu_events/powerpc: Add hv_24x7 core level metric events
>>
>>  tools/perf/arch/powerpc/util/header.c |   7 +-
>>  .../arch/powerpc/power9/nest_metrics.json |  27 +-
>>  .../arch/x86/broadwellde/uncore-cache.json|  62 ++--
>>  .../arch/x86/broadwellde/uncore-memory.json   |  18 +-
>>  .../arch/x86/broadwellde/uncore-power.json|  18 +-
>>  .../arch/x86/broadwellx/uncore-cache.json |  62 ++--
>>  .../x86/broadwellx/uncore-interconnect.json   |   6 +-
>>  .../arch/x86/broadwellx/uncore-memory.json|  18 +-
>>  .../arch/x86/broadwellx/uncore-power.json |  18 +-
>>  .../arch/x86/cascadelakex/uncore-memory.json  |  64 ++--
>>  .../arch/x86/cascadelakex/uncore-other.json   | 332 +-
>>  .../arch/x86/haswellx/uncore-cache.json   |  62 ++--
>>  .../x86/haswellx/uncore-interconnect.json |   6 +-
>>  .../arch/x86/haswellx/uncore-memory.json  |  18 +-
>>  .../arch/x86/haswellx/uncore-power.json   |  18 +-
>>  .../arch/x86/ivytown/uncore-cache.json|  62 ++--
>>  .../arch/x86/ivytown/uncore-interconnect.json |  10 +-
>>  .../arch/x86/ivytown/uncore-memory.json   |  16 +-
>>  .../arch/x86/ivytown/uncore-power.json|  52 +--
>>  .../arch/x86/jaketown/uncore-cache.json   |  40 +--
>>  .../x86/jaketown/uncore-interconnect.json |  10 +-
>>  .../arch/x86/jaketown/uncore-memory.json  |  18 +-
>>  .../arch/x86/jaketown/uncore-power.json   |  52 +--
>>  .../x86/knightslanding/uncore-memory.json |   8 +-
>>  .../arch/x86/skylakex/uncore-memory.json  |  36 +-
>>  .../arch/x86/skylakex/uncore-other.json   | 220 ++--
>>  .../arch/x86/tremontx/uncore-memory.json  |  14 +-
>>  .../arch/x86/tremontx/uncore-other.json   |  70 ++--
>>  .../arch/x86/tremontx/uncore-power.json   |   2 +-
>>  tools/perf/pmu-events/jevents.c   |  45 ++-
>>  tools/perf/pmu-events/jevents.h   |   2 +-
>>  tools/perf/pmu-events/pmu-events.h|   8 +-
>>  tools/perf/tests/pmu-events.c |   8 +-
>>  tools/perf/util/metricgroup.c |   5 +-
>>  tools/perf/util/metricgroup.h |   3 +-
>>  tools/perf/util/pmu.c |   6 +-
>>  36 files changed, 729 insertions(+), 694 deletions(-)
>>
>> -- 
>> 2.26.2
>>
> 


Re: [RFC v2 3/5] perf jevents: Add support for parsing perchip/percore events

2020-07-14 Thread kajoljain



On 7/13/20 12:25 AM, Jiri Olsa wrote:
> On Tue, Jul 07, 2020 at 05:53:12PM +0530, Kajol Jain wrote:
>> Added the "PerChip" field  in enum so that perf knows they are
>> per chip events.
>>
>> Added the "PerCore" field in enum so that perf knows they are
>> per core events and add these fields to pmu_event structure.
>>
>> Similar to the way we had "PerPkg field
>> to specify perpkg events.
>>
>> Signed-off-by: Kajol Jain 
>> ---
>>  tools/perf/pmu-events/jevents.c| 8 +++-
>>  tools/perf/pmu-events/pmu-events.h | 4 +++-
>>  2 files changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/perf/pmu-events/jevents.c 
>> b/tools/perf/pmu-events/jevents.c
>> index b2f59f0af63d..1f65047db000 100644
>> --- a/tools/perf/pmu-events/jevents.c
>> +++ b/tools/perf/pmu-events/jevents.c
>> @@ -54,13 +54,19 @@ int verbose;
>>  char *prog;
>>  
>>  enum aggr_mode_class {
>> -PerPkg = 1
>> +PerChip = 0,
> 
> is there a reason for the values? just wonder if it's wise to have PerChip == 
> 0,
> and why you would not continue with forward when PerPkg is 1

Hi Jiri,
 Yes, there is no reason for having particular values, It just added to get 
which parameter
we are referring. I can sure continue it after Perpkg.

Thanks,
Kajol Jain

> 
> jirka
> 
>> +PerPkg = 1,
>> +PerCore = 2
>>  };
>>  
> 
> SNIP
> 


Re: [RFC v2 1/5] perf/pmu-events/jevents: Add enum to store aggregation like PerPkg

2020-07-14 Thread kajoljain



On 7/13/20 12:25 AM, Jiri Olsa wrote:
> On Tue, Jul 07, 2020 at 05:53:10PM +0530, Kajol Jain wrote:
> 
> SNIP
> 
>>  }
>>  
>> diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
>> index 93fe72a9dc0b..3cafbb320d68 100644
>> --- a/tools/perf/util/pmu.c
>> +++ b/tools/perf/util/pmu.c
>> @@ -306,7 +306,7 @@ static bool perf_pmu_merge_alias(struct perf_pmu_alias 
>> *newalias,
>>  static int __perf_pmu__new_alias(struct list_head *list, char *dir, char 
>> *name,
>>   char *desc, char *val,
>>   char *long_desc, char *topic,
>> - char *unit, char *perpkg,
>> + char *unit, char *aggr_mode,
>>   char *metric_expr,
>>   char *metric_name,
>>   char *deprecated)
>> @@ -378,7 +378,7 @@ static int __perf_pmu__new_alias(struct list_head *list, 
>> char *dir, char *name,
>>  return -1;
>>  snprintf(alias->unit, sizeof(alias->unit), "%s", unit);
>>  }
>> -alias->per_pkg = perpkg && sscanf(perpkg, "%d", ) == 1 && num == 1;
>> +alias->per_pkg = aggr_mode && sscanf(aggr_mode, "%d", ) == 1 && num 
>> == 1;
> 
> should you rather use 'num == PerPkg' instead 'num == 1' ?

Hi Jiri,
 Thanks for reviewing the patchset. Sure I will update it.

Thanks,
Kajol Jain
> 
> jirka
> 


Re: [RFC 1/3] perf jevents: Add support for parsing perchip/percore events

2020-07-07 Thread kajoljain



On 7/6/20 6:27 PM, Jiri Olsa wrote:
> On Fri, Jul 03, 2020 at 11:50:28AM +0530, kajoljain wrote:
> 
> SNIP
> 
>>  ]
>> diff --git a/tools/perf/pmu-events/jevents.c 
>> b/tools/perf/pmu-events/jevents.c
>> index fa86c5f997cc..dd2b14cc147c 100644
>> --- a/tools/perf/pmu-events/jevents.c
>> +++ b/tools/perf/pmu-events/jevents.c
>> @@ -53,6 +53,23 @@
>>  int verbose;
>>  char *prog;
>>  
>> +enum event_class {
>> +PerChip = 0,
>> +PerPkg = 1,
>> +PerCore = 2
>> +};
> 
> could you please split this into patch that changes perpkg
> into the class type string and another that adds new PerChip/PerCore?
> 

Hi Jiri,
   Thanks for reviewing the prototype changes. Sure I will split it and
and send next version out.

>> +
>> +enum event_class convert(const char* event_class_type) {
>> +
>> +if (!strcmp(event_class_type, "PerCore"))
>> +return PerCore;
>> +else if (!strcmp(event_class_type, "PerChip"))
>> +return PerChip;
>> +else if (!strcmp(event_class_type, "PerPkg"))
>> +return PerPkg;
>> +return -1;
>> +}
>> +
>>  int eprintf(int level, int var, const char *fmt, ...)
>>  {
>>  
>> @@ -320,7 +337,7 @@ static void print_events_table_prefix(FILE *fp, const 
>> char *tblname)
>>  
>>  static int print_events_table_entry(void *data, char *name, char *event,
>>  char *desc, char *long_desc,
>> -char *pmu, char *unit, char *perpkg,
>> +char *pmu, char *unit, char 
>> *event_class_type,
> 
> maybe 'aggregation' or 'aggr_mode' would be better name than event_class_type?
>

Sure, will update.

Thanks,
Kajol Jain
 
> thanks,
> jirka
> 


Re: [RFC 1/3] perf jevents: Add support for parsing perchip/percore events

2020-07-03 Thread kajoljain



On 6/25/20 7:38 PM, Ian Rogers wrote:
> On Thu, Jun 25, 2020 at 4:47 AM Kajol Jain  wrote:
>>
>> Set up the "PerChip" field  so that perf knows they are
>> per chip events.
>>
>> Set up the "PerCore" field  so that perf knows they are
>> per core events and add these fields to pmu_event structure.
>>
>> Similar to the way we had "PerPkg field
>> to specify perpkg events.
>>
>> Signed-off-by: Kajol Jain 
>> ---
>>  tools/perf/pmu-events/jevents.c| 34 --
>>  tools/perf/pmu-events/jevents.h|  3 ++-
>>  tools/perf/pmu-events/pmu-events.h |  2 ++
>>  3 files changed, 32 insertions(+), 7 deletions(-)
>>
>> diff --git a/tools/perf/pmu-events/jevents.c 
>> b/tools/perf/pmu-events/jevents.c
>> index fa86c5f997cc..21fd7990ded5 100644
>> --- a/tools/perf/pmu-events/jevents.c
>> +++ b/tools/perf/pmu-events/jevents.c
>> @@ -323,7 +323,8 @@ static int print_events_table_entry(void *data, char 
>> *name, char *event,
>> char *pmu, char *unit, char *perpkg,
>> char *metric_expr,
>> char *metric_name, char *metric_group,
>> -   char *deprecated, char 
>> *metric_constraint)
>> +   char *deprecated, char *perchip, char 
>> *percore,
>> +   char *metric_constraint)
>>  {
>> struct perf_entry_data *pd = data;
>> FILE *outfp = pd->outfp;
>> @@ -357,6 +358,10 @@ static int print_events_table_entry(void *data, char 
>> *name, char *event,
>> fprintf(outfp, "\t.metric_group = \"%s\",\n", metric_group);
>> if (deprecated)
>> fprintf(outfp, "\t.deprecated = \"%s\",\n", deprecated);
>> +   if (perchip)
>> +   fprintf(outfp, "\t.perchip = \"%s\",\n", perchip);
>> +   if (percore)
>> +   fprintf(outfp, "\t.percore = \"%s\",\n", percore);
>> if (metric_constraint)
>> fprintf(outfp, "\t.metric_constraint = \"%s\",\n", 
>> metric_constraint);
>> fprintf(outfp, "},\n");
>> @@ -378,6 +383,8 @@ struct event_struct {
>> char *metric_group;
>> char *deprecated;
>> char *metric_constraint;
>> +   char *perchip;
>> +   char *percore;
>>  };
>>
>>  #define ADD_EVENT_FIELD(field) do { if (field) {   \
>> @@ -406,6 +413,8 @@ struct event_struct {
>> op(metric_name);\
>> op(metric_group);   \
>> op(deprecated); \
>> +   op(perchip);\
>> +   op(percore);\
>>  } while (0)
>>
>>  static LIST_HEAD(arch_std_events);
>> @@ -425,7 +434,8 @@ static int save_arch_std_events(void *data, char *name, 
>> char *event,
>> char *desc, char *long_desc, char *pmu,
>> char *unit, char *perpkg, char *metric_expr,
>> char *metric_name, char *metric_group,
>> -   char *deprecated, char *metric_constraint)
>> +   char *deprecated, char *perchip, char 
>> *percore,
>> +   char *metric_constraint)
>>  {
>> struct event_struct *es;
>>
>> @@ -489,7 +499,8 @@ try_fixup(const char *fn, char *arch_std, char **event, 
>> char **desc,
>>   char **name, char **long_desc, char **pmu, char **filter,
>>   char **perpkg, char **unit, char **metric_expr, char **metric_name,
>>   char **metric_group, unsigned long long eventcode,
>> - char **deprecated, char **metric_constraint)
>> + char **deprecated, char **perchip, char **percore,
>> + char **metric_constraint)
>>  {
>> /* try to find matching event from arch standard values */
>> struct event_struct *es;
>> @@ -518,7 +529,8 @@ int json_events(const char *fn,
>>   char *pmu, char *unit, char *perpkg,
>>   char *metric_expr,
>>   char *metric_name, char *metric_group,
>> - char *deprecated, char *metric_constraint),
>> + char *deprecated, char *perchip, char *percore,
>> + char *metric_constraint),
>>   void *data)
>>  {
>> int err;
>> @@ -548,6 +560,8 @@ int json_events(const char *fn,
>> char *metric_name = NULL;
>> char *metric_group = NULL;
>> char *deprecated = NULL;
>> +   char *perchip = NULL;
>> +   char *percore = NULL;
>> char *metric_constraint = NULL;
>> char *arch_std = NULL;
>> unsigned long long eventcode = 0;
>> @@ -629,6 +643,10 @@ int json_events(const char *fn,
>>   

Re: [PATCH v2 0/7] Share events between metrics

2020-05-22 Thread kajoljain



On 5/20/20 11:50 PM, Ian Rogers wrote:
> Metric groups contain metrics. Metrics create groups of events to
> ideally be scheduled together. Often metrics refer to the same events,
> for example, a cache hit and cache miss rate. Using separate event
> groups means these metrics are multiplexed at different times and the
> counts don't sum to 100%. More multiplexing also decreases the
> accuracy of the measurement.
> 
> This change orders metrics from groups or the command line, so that
> the ones with the most events are set up first. Later metrics see if
> groups already provide their events, and reuse them if
> possible. Unnecessary events and groups are eliminated.
> 
> The option --metric-no-group is added so that metrics aren't placed in
> groups. This affects multiplexing and may increase sharing.
> 
> The option --metric-mo-merge is added and with this option the
> existing grouping behavior is preserved.
> 
> Using skylakex metrics I ran the following shell code to count the
> number of events for each metric group (this ignores metric groups
> with a single metric, and one of the duplicated TopdownL1 and
> TopDownL1 groups):
> 
> for i in all Branches BrMispredicts Cache_Misses FLOPS Instruction_Type 
> Memory_BW Pipeline Power SMT Summary TopdownL1 TopdownL1_SMT
> do
>   echo Metric group: $i
>   echo -n " - No merging (old default, now --metric-no-merge): "
>   /tmp/perf/perf stat -a --metric-no-merge -M $i sleep 1 2>&1 | grep -v "^ 
> *#" | egrep " +[0-9,.]+ [^s]" | wc -l
>   echo -n " - Merging over metrics (new default) : "
>   /tmp/perf/perf stat -a -M $i sleep 1 2>&1 | grep -v "^ *#" | egrep " 
> +[0-9,.]+ [^s]"|wc -l
>   echo -n " - No event groups and merging (--metric-no-group): "
>   /tmp/perf/perf stat -a --metric-no-group -M $i sleep 1 2>&1 | grep -v "^ 
> *#" | egrep " +[0-9,.]+ [^s]"|wc -l
> done
> 
> Metric group: all
>  - No merging (old default, now --metric-no-merge): 193
>  - Merging over metrics (new default) : 142
>  - No event groups and merging (--metric-no-group): 84
> Metric group: Branches
>  - No merging (old default, now --metric-no-merge): 8
>  - Merging over metrics (new default) : 8
>  - No event groups and merging (--metric-no-group): 4
> Metric group: BrMispredicts
>  - No merging (old default, now --metric-no-merge): 11
>  - Merging over metrics (new default) : 11
>  - No event groups and merging (--metric-no-group): 10
> Metric group: Cache_Misses
>  - No merging (old default, now --metric-no-merge): 11
>  - Merging over metrics (new default) : 9
>  - No event groups and merging (--metric-no-group): 6
> Metric group: FLOPS
>  - No merging (old default, now --metric-no-merge): 18
>  - Merging over metrics (new default) : 10
>  - No event groups and merging (--metric-no-group): 10
> Metric group: Instruction_Type
>  - No merging (old default, now --metric-no-merge): 6
>  - Merging over metrics (new default) : 6
>  - No event groups and merging (--metric-no-group): 4
> Metric group: Pipeline
>  - No merging (old default, now --metric-no-merge): 6
>  - Merging over metrics (new default) : 6
>  - No event groups and merging (--metric-no-group): 5
> Metric group: Power
>  - No merging (old default, now --metric-no-merge): 16
>  - Merging over metrics (new default) : 16
>  - No event groups and merging (--metric-no-group): 10
> Metric group: SMT
>  - No merging (old default, now --metric-no-merge): 11
>  - Merging over metrics (new default) : 8
>  - No event groups and merging (--metric-no-group): 7
> Metric group: Summary
>  - No merging (old default, now --metric-no-merge): 19
>  - Merging over metrics (new default) : 17
>  - No event groups and merging (--metric-no-group): 17
> Metric group: TopdownL1
>  - No merging (old default, now --metric-no-merge): 16
>  - Merging over metrics (new default) : 7
>  - No event groups and merging (--metric-no-group): 7
> Metric group: TopdownL1_SMT
>  - No merging (old default, now --metric-no-merge): 24
>  - Merging over metrics (new default) : 7
>  - No event groups and merging (--metric-no-group): 7
> 
> There are 5 out of 12 metric groups where no events are shared, such
> as Power, however, disabling grouping of events always reduces the
> number of events.
> 
> The result for Memory_BW needs explanation:
> 
> Metric group: Memory_BW
>  - No merging (old default, now --metric-no-merge): 9
>  - Merging over metrics (new default) : 5
>  - No event groups and merging (--metric-no-group): 11
> 
> Both with and without merging the groups fail to be set up and so the
> event counts here are for broken metrics. The --metric-no-group number
> is accurate as all the events are scheduled. Ideally a constraint
> would be added for these metrics in the json code to avoid grouping.
> 
> v2. rebases on kernel/git/acme/linux.git branch tmp.perf/core, fixes a
> missing 

Re: [PATCH v5 0/5] perf stat: Support overall statistics for interval mode

2020-05-14 Thread kajoljain



On 5/14/20 11:06 AM, Jin Yao wrote:
> Currently perf-stat supports to print counts at regular interval (-I),
> but it's not very easy for user to get the overall statistics.
> 
> With this patchset, it supports to report the summary at the end of
> interval output.
> 
> For example,
> 
>  root@kbl-ppc:~# perf stat -e cycles -I1000 --interval-count 2
>  #   time counts unit events
>   1.000412064  2,281,114  cycles
>   2.001383658  2,547,880  cycles
> 
>   Performance counter stats for 'system wide':
> 
>   4,828,994  cycles
> 
> 2.002860349 seconds time elapsed
> 
>  root@kbl-ppc:~# perf stat -e cycles,instructions -I1000 --interval-count 2
>  #   time counts unit events
>   1.000389902  1,536,093  cycles
>   1.000389902420,226  instructions  #0.27 
>  insn per cycle
>   2.001433453  2,213,952  cycles
>   2.001433453735,465  instructions  #0.33 
>  insn per cycle
> 
>   Performance counter stats for 'system wide':
> 
>   3,750,045  cycles
>   1,155,691  instructions  #0.31  insn per cycle
> 
> 2.003023361 seconds time elapsed
> 
>  root@kbl-ppc:~# perf stat -M CPI,IPC -I1000 --interval-count 2
>  #   time counts unit events
>   1.000435121905,303  inst_retired.any  #  
> 2.9 CPI
>   1.000435121  2,663,333  cycles
>   1.000435121914,702  inst_retired.any  #  
> 0.3 IPC
>   1.000435121  2,676,559  cpu_clk_unhalted.thread
>   2.001615941  1,951,092  inst_retired.any  #  
> 1.8 CPI
>   2.001615941  3,551,357  cycles
>   2.001615941  1,950,837  inst_retired.any  #  
> 0.5 IPC
>   2.001615941  3,551,044  cpu_clk_unhalted.thread
> 
>   Performance counter stats for 'system wide':
> 
>   2,856,395  inst_retired.any  #  2.2 CPI
>   6,214,690  cycles
>   2,865,539  inst_retired.any  #  0.5 IPC
>   6,227,603  cpu_clk_unhalted.thread
> 
> 2.003403078 seconds time elapsed

Hi Jin,
Reporting the summary will be great for understanding overall stats. 
So, Before the
patch where we are reseting rt_stat before read_counters to make sure, whatever 
printing
in final aggregate is as per counts on that interval, 

we used to update stats->means and other info as described in 

RFC: https://lkml.org/lkml/2020/3/24/158

Now, stats->means is same as counts which we are using in generic_metric 
function. Is this expected behavior?
I am not sure, if data like stats->means and all suppose to update per interval 
or we are using it somewhere else.

So, As we call update_stats for each event and for each interval, can we 
somehow use that
to print overall stats maybe by adding some var in `struct stats` to keep count 
of total counts for that event.
Please let me know if my understanding is fine.

Thanks,
Kajol Jain


 
> 
>  v5:
>  ---
>  1. Create new patch "perf stat: Save aggr value to first member
> of prev_raw_counts".
> 
>  2. Call perf_evlist__save_aggr_prev_raw_counts to save aggr value
> to first member of prev_raw_counts for AGGR_GLOBAL. Then next,
> perf_stat_process_counter can create aggr values from per cpu
> values.
> 
>  Following patches are impacted in v5:
> perf stat: Copy counts from prev_raw_counts to evsel->counts
> perf stat: Save aggr value to first member of prev_raw_counts
> perf stat: Report summary for interval mode
> 
>  v4:
>  ---
>  1. Create runtime_stat_reset.
> 
>  2. Zero the aggr in perf_counts__reset and use it to reset
> prev_raw_counts.
> 
>  3. Move affinity setup and read_counter_cpu to a new function
> read_affinity_counters. It's only called when stat_config.summary
> is not set.
> 
>  v3:
>  ---
>  1. 'perf stat: Fix wrong per-thread runtime stat for interval mode'
> is a new patch which fixes an existing issue found in test.
> 
>  2. We use the prev_raw_counts for summary counts. Drop the summary_counts in 
> v2.
> 
>  3. Fix some issues.
> 
>  v2:
>  ---
>  Rebase to perf/core branch
> 
> Jin Yao (5):
>   perf stat: Fix wrong per-thread runtime stat for interval mode
>   perf counts: Reset prev_raw_counts counts
>   perf stat: Copy counts from prev_raw_counts to evsel->counts
>   perf stat: Save aggr value to first member of prev_raw_counts
>   perf stat: Report summary for interval mode
> 
>  tools/perf/builtin-stat.c | 101 ++
>  tools/perf/util/counts.c  |   4 +-
>  tools/perf/util/counts.h  |   1 +
>  tools/perf/util/stat.c|  43 +---
>  tools/perf/util/stat.h|   3 ++
>  5 files changed, 113 insertions(+), 39 deletions(-)
> 


Re: [PATCH 2/2] perf: Add missing metrics to POWER9 'cpi_breakdown'

2020-05-08 Thread kajoljain



On 5/7/20 9:58 PM, Paul A. Clarke wrote:
> From: "Paul A. Clarke" 
> 
> Add the following metrics to the POWER9 'cpi_breakdown' metricgroup:
> - ict_noslot_br_mpred_cpi
> - ict_noslot_br_mpred_icmiss_cpi
> - ict_noslot_cyc_other_cpi
> - ict_noslot_disp_held_cpi
> - ict_noslot_disp_held_hb_full_cpi
> - ict_noslot_disp_held_issq_cpi
> - ict_noslot_disp_held_other_cpi
> - ict_noslot_disp_held_sync_cpi
> - ict_noslot_disp_held_tbegin_cpi
> - ict_noslot_ic_l2_cpi
> - ict_noslot_ic_l3_cpi
> - ict_noslot_ic_l3miss_cpi
> - ict_noslot_ic_miss_cpi
> 
> Signed-off-by: Paul A. Clarke 

Reviewed-by: Kajol Jain 

Thanks,
Kajol Jain
> ---
>  .../arch/powerpc/power9/metrics.json  | 143 ++
>  1 file changed, 78 insertions(+), 65 deletions(-)
> 
> diff --git a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json 
> b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
> index 811c2a8c1c9e..6169351a72c8 100644
> --- a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
> +++ b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
> @@ -207,6 +207,84 @@
>  "MetricGroup": "cpi_breakdown",
>  "MetricName": "fxu_stall_cpi"
>  },
> +{
> +"BriefDescription": "Ict empty for this thread due to branch 
> mispred",
> +"MetricExpr": "PM_ICT_NOSLOT_BR_MPRED/PM_RUN_INST_CMPL",
> +"MetricGroup": "cpi_breakdown",
> +"MetricName": "ict_noslot_br_mpred_cpi"
> +},
> +{
> +"BriefDescription": "Ict empty for this thread due to Icache Miss 
> and branch mispred",
> +"MetricExpr": "PM_ICT_NOSLOT_BR_MPRED_ICMISS/PM_RUN_INST_CMPL",
> +"MetricGroup": "cpi_breakdown",
> +"MetricName": "ict_noslot_br_mpred_icmiss_cpi"
> +},
> +{
> +"BriefDescription": "ICT other stalls",
> +"MetricExpr": "(PM_ICT_NOSLOT_CYC - PM_ICT_NOSLOT_IC_MISS - 
> PM_ICT_NOSLOT_BR_MPRED_ICMISS - PM_ICT_NOSLOT_BR_MPRED - 
> PM_ICT_NOSLOT_DISP_HELD)/PM_RUN_INST_CMPL",
> +"MetricGroup": "cpi_breakdown",
> +"MetricName": "ict_noslot_cyc_other_cpi"
> +},
> +{
> +"BriefDescription": "Cycles in which the NTC instruciton is held at 
> dispatch for any reason",
> +"MetricExpr": "PM_ICT_NOSLOT_DISP_HELD/PM_RUN_INST_CMPL",
> +"MetricGroup": "cpi_breakdown",
> +"MetricName": "ict_noslot_disp_held_cpi"
> +},
> +{
> +"BriefDescription": "Ict empty for this thread due to dispatch holds 
> because the History Buffer was full. Could be GPR/VSR/VMR/FPR/CR/XVF",
> +"MetricExpr": "PM_ICT_NOSLOT_DISP_HELD_HB_FULL/PM_RUN_INST_CMPL",
> +"MetricGroup": "cpi_breakdown",
> +"MetricName": "ict_noslot_disp_held_hb_full_cpi"
> +},
> +{
> +"BriefDescription": "Ict empty for this thread due to dispatch hold 
> on this thread due to Issue q full, BRQ full, XVCF Full, Count cache, Link, 
> Tar full",
> +"MetricExpr": "PM_ICT_NOSLOT_DISP_HELD_ISSQ/PM_RUN_INST_CMPL",
> +"MetricGroup": "cpi_breakdown",
> +"MetricName": "ict_noslot_disp_held_issq_cpi"
> +},
> +{
> +"BriefDescription": "ICT_NOSLOT_DISP_HELD_OTHER_CPI",
> +"MetricExpr": "(PM_ICT_NOSLOT_DISP_HELD - 
> PM_ICT_NOSLOT_DISP_HELD_HB_FULL - PM_ICT_NOSLOT_DISP_HELD_SYNC - 
> PM_ICT_NOSLOT_DISP_HELD_TBEGIN - 
> PM_ICT_NOSLOT_DISP_HELD_ISSQ)/PM_RUN_INST_CMPL",
> +"MetricGroup": "cpi_breakdown",
> +"MetricName": "ict_noslot_disp_held_other_cpi"
> +},
> +{
> +"BriefDescription": "Dispatch held due to a synchronizing 
> instruction at dispatch",
> +"MetricExpr": "PM_ICT_NOSLOT_DISP_HELD_SYNC/PM_RUN_INST_CMPL",
> +"MetricGroup": "cpi_breakdown",
> +"MetricName": "ict_noslot_disp_held_sync_cpi"
> +},
> +{
> +"BriefDescription": "the NTC instruction is being held at dispatch 
> because it is a tbegin instruction and there is an older tbegin in the 
> pipeline that must complete before the younger tbegin can dispatch",
> +"MetricExpr": "PM_ICT_NOSLOT_DISP_HELD_TBEGIN/PM_RUN_INST_CMPL",
> +"MetricGroup": "cpi_breakdown",
> +"MetricName": "ict_noslot_disp_held_tbegin_cpi"
> +},
> +{
> +"BriefDescription": "ICT_NOSLOT_IC_L2_CPI",
> +"MetricExpr": "(PM_ICT_NOSLOT_IC_MISS - PM_ICT_NOSLOT_IC_L3 - 
> PM_ICT_NOSLOT_IC_L3MISS)/PM_RUN_INST_CMPL",
> +"MetricGroup": "cpi_breakdown",
> +"MetricName": "ict_noslot_ic_l2_cpi"
> +},
> +{
> +"BriefDescription": "Ict empty for this thread due to icache misses 
> that were sourced from the local L3",
> +"MetricExpr": "PM_ICT_NOSLOT_IC_L3/PM_RUN_INST_CMPL",
> +"MetricGroup": "cpi_breakdown",
> +"MetricName": "ict_noslot_ic_l3_cpi"
> +},
> +{
> +"BriefDescription": "Ict empty for this thread due to icache misses 
> that were sourced from beyond the local L3. The source could be 
> local/remote/distant memory or another core's cache",
> +

Re: [PATCH 1/2] perf: Fix POWER9 metric 'lsu_other_stall_cpi'

2020-05-08 Thread kajoljain



On 5/8/20 12:01 PM, kajoljain wrote:
> 
> 
> On 5/7/20 9:58 PM, Paul A. Clarke wrote:
>> From: "Paul A. Clarke" 
>>
>> The metric definition is too long for the current value of EXPR_MAX_OTHER.
>> Increase the value EXPR_MAX_OTHER sufficiently to allow
>> 'lsu_other_stall_cpi' to build properly.
>>
>> Before:
>> --
>> $ perf list | grep lsu_other
>>   lsu_other_stall_cpi
>> # perf stat -a --metrics lsu_other_stall_cpi /bin/sleep 1
>> Cannot find metric or group `lsu_other_stall_cpi'
>>
>>  Usage: perf stat [] []
>>
>> -M, --metrics 
>>   monitor specified metrics or metric groups 
>> (separated by ,)
>> --
>>
>> After:
>> --
>> # perf stat -a --metrics lsu_other_stall_cpi /bin/sleep 1
>>
>>  Performance counter stats for 'system wide':
>>
>>438,086,889  pm_cmplu_stall_lsu# 1.74 
>> lsu_other_stall_cpi
>> [...]
>> --
>>
>> Signed-off-by: Paul A. Clarke 
>> ---
>>  tools/perf/util/expr.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tools/perf/util/expr.h b/tools/perf/util/expr.h
>> index 87d627bb699b..a0991959cca4 100644
>> --- a/tools/perf/util/expr.h
>> +++ b/tools/perf/util/expr.h
>> @@ -2,7 +2,7 @@
>>  #ifndef PARSE_CTX_H
>>  #define PARSE_CTX_H 1
>>  
>> -#define EXPR_MAX_OTHER 20
>> +#define EXPR_MAX_OTHER 28
> 
> Hi Paul,
>   Ian already add one patch to increase EXPR_MAX_OTHER value to 68 which 
> is Acked-by: Jiri

Sorry its 64 not 68 and I missed earlier response from Arnaldo and Ian.

Thanks,
Kajol Jain
> 
> Link to the patch: https://lkml.org/lkml/2020/5/1/1023
> 
> Thanks,
> Kajol Jain
> 
>>  #define MAX_PARSE_ID EXPR_MAX_OTHER
>>  
>>  struct expr_parse_id {
>>


Re: [PATCH 1/2] perf: Fix POWER9 metric 'lsu_other_stall_cpi'

2020-05-08 Thread kajoljain



On 5/7/20 9:58 PM, Paul A. Clarke wrote:
> From: "Paul A. Clarke" 
> 
> The metric definition is too long for the current value of EXPR_MAX_OTHER.
> Increase the value EXPR_MAX_OTHER sufficiently to allow
> 'lsu_other_stall_cpi' to build properly.
> 
> Before:
> --
> $ perf list | grep lsu_other
>   lsu_other_stall_cpi
> # perf stat -a --metrics lsu_other_stall_cpi /bin/sleep 1
> Cannot find metric or group `lsu_other_stall_cpi'
> 
>  Usage: perf stat [] []
> 
> -M, --metrics 
>   monitor specified metrics or metric groups 
> (separated by ,)
> --
> 
> After:
> --
> # perf stat -a --metrics lsu_other_stall_cpi /bin/sleep 1
> 
>  Performance counter stats for 'system wide':
> 
>438,086,889  pm_cmplu_stall_lsu# 1.74 
> lsu_other_stall_cpi
> [...]
> --
> 
> Signed-off-by: Paul A. Clarke 
> ---
>  tools/perf/util/expr.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/perf/util/expr.h b/tools/perf/util/expr.h
> index 87d627bb699b..a0991959cca4 100644
> --- a/tools/perf/util/expr.h
> +++ b/tools/perf/util/expr.h
> @@ -2,7 +2,7 @@
>  #ifndef PARSE_CTX_H
>  #define PARSE_CTX_H 1
>  
> -#define EXPR_MAX_OTHER 20
> +#define EXPR_MAX_OTHER 28

Hi Paul,
Ian already add one patch to increase EXPR_MAX_OTHER value to 68 which 
is Acked-by: Jiri

Link to the patch: https://lkml.org/lkml/2020/5/1/1023

Thanks,
Kajol Jain

>  #define MAX_PARSE_ID EXPR_MAX_OTHER
>  
>  struct expr_parse_id {
> 


Re: [PATCH v7 2/5] powerpc/hv-24x7: Add rtas call in hv-24x7 driver to get processor details

2020-05-06 Thread kajoljain



On 4/29/20 5:01 PM, Michael Ellerman wrote:
> Hi Kajol,
> 
> Some comments inline ...
> 
> Kajol Jain  writes:
>> For hv_24x7 socket/chip level events, specific chip-id to which
>> the data requested should be added as part of pmu events.
>> But number of chips/socket in the system details are not exposed.
>>
>> Patch implements read_sys_info_pseries() to get system
>> parameter values like number of sockets and chips per socket.
>> Rtas_call with token "PROCESSOR_MODULE_INFO"
>> is used to get these values.
>>
>> Sub-sequent patch exports these values via sysfs.
>>
>> Patch also make these parameters default to 1.
>>
>> Signed-off-by: Kajol Jain 
>> ---
>>  arch/powerpc/perf/hv-24x7.c  | 72 
>>  arch/powerpc/platforms/pseries/pseries.h |  3 +
>>  2 files changed, 75 insertions(+)
>>
>> diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
>> index 48e8f4b17b91..9ae00f29bd21 100644
>> --- a/arch/powerpc/perf/hv-24x7.c
>> +++ b/arch/powerpc/perf/hv-24x7.c
>> @@ -20,6 +20,11 @@
>>  #include 
>>  #include 
>>  
>> +#ifdef CONFIG_PPC_RTAS
> 
> This driver can only be build on pseries, and pseries always selects
> RTAS. So the ifdef is unncessary.

Hi Michael,
Thanks for review, I will remove this check.

> 
>> +#include 
>> +#include <../../platforms/pseries/pseries.h>
>> +#endif
> 
> That's not really what the platform header is intended for.
> 
> You should put the extern in arch/powerpc/include/asm somewhere.
> 
> Maybe rtas.h
> 
>> @@ -57,6 +62,69 @@ static bool is_physical_domain(unsigned domain)
>>  }
>>  }
>>  
>> +#ifdef CONFIG_PPC_RTAS
> 
> Not needed.
> 
>> +#define PROCESSOR_MODULE_INFO   43
> 
> Please document where these come from, presumably LoPAPR somewhere?
> 

Sure, will add the details.

>> +#define PROCESSOR_MAX_LENGTH(8 * 1024)
>> +
>> +static int strbe16toh(const char *buf, int offset)
>> +{
>> +return (buf[offset] << 8) + buf[offset + 1];
>> +}
> 
> I'm confused by this. "str" implies string, a string is an array of
> bytes and has no endian. But then be16 implies it's an array of __be16,
> in which case buf should be a __be16 *.
> 

Yes right, actually I was following implementation in util-linux. But what you
suggested make more sense, will update accordingly.

>> +
>> +static u32  physsockets;/* Physical sockets */
>> +static u32  physchips;  /* Physical chips */
> 
> No tabs there please.

Sure will update.

> 
>> +
>> +/*
>> + * Function read_sys_info_pseries() make a rtas_call which require
>> + * data buffer of size 8K. As standard 'rtas_data_buf' is of size
>> + * 4K, we are adding new local buffer 'rtas_local_data_buf'.
>> + */
>> +char rtas_local_data_buf[PROCESSOR_MAX_LENGTH] __cacheline_aligned;
> 
> static?
> 
>> +/*
>> + * read_sys_info_pseries()
>> + * Retrieve the number of sockets and chips per socket details
>> + * through the get-system-parameter rtas call.
>> + */
>> +void read_sys_info_pseries(void)
>> +{
>> +int call_status, len, ntypes;
>> +
>> +/*
>> + * Making system parameter: chips and sockets default to 1.
>> + */
>> +physsockets = 1;
>> +physchips = 1;
>> +memset(rtas_local_data_buf, 0, PROCESSOR_MAX_LENGTH);
>> +spin_lock(_data_buf_lock);
> 
> You're not using the rtas_data_buf, so why are you taking the
> rtas_data_buf_lock?

Sure, I will add new lock specific for rtas_local_data_buf

> 
>> +call_status = rtas_call(rtas_token("ibm,get-system-parameter"), 3, 1,
>> +NULL,
>> +PROCESSOR_MODULE_INFO,
>> +__pa(rtas_local_data_buf),
>> +PROCESSOR_MAX_LENGTH);
>> +
>> +spin_unlock(_data_buf_lock);
>> +
>> +if (call_status != 0) {
>> +pr_info("%s %s Error calling get-system-parameter (0x%x)\n",
>> +__FILE__, __func__, call_status);
> 
> pr_err(), don't use __FILE__, this file already uses pr_fmt(). Not sure
> __func__ is really necessary either
> 
>   return;
> 
> Then you can deindent the next block.
> 
>> +} else {
>> +rtas_local_data_buf[PROCESSOR_MAX_LENGTH - 1] = '\0';
>> +len = strbe16toh(rtas_local_data_buf, 0);
> 
> Why isn't the buffer a __be16 array, and then you just use be16_to_cpu() ?
> 
>> +if (len < 6)
>> +return;
>> +
>> +ntypes = strbe16toh(rtas_local_data_buf, 2);
>> +
>> +if (!ntypes)
>> +return;
> 
> What is ntype
ntype specify processor module type

> 
>> +physsockets = strbe16toh(rtas_local_data_buf, 4);
>> +physchips = strbe16toh(rtas_local_data_buf, 6);
>> +}
>> +}
>> +#endif /* CONFIG_PPC_RTAS */
>> +
>>  /* Domains for which more than one result element are returned for each 
>> event. */
>>  static bool domain_needs_aggregation(unsigned int domain)
>>  {
>> @@ -1605,6 +1673,10 @@ static int hv_24x7_init(void)

Re: [PATCH v7 5/5] powerpc/hv-24x7: Update post_mobility_fixup() to handle migration

2020-05-05 Thread kajoljain



On 4/29/20 5:07 PM, Michael Ellerman wrote:
> Kajol Jain  writes:
>> Function 'read_sys_info_pseries()' is added to get system parameter
>> values like number of sockets and chips per socket.
>> and it gets these details via rtas_call with token
>> "PROCESSOR_MODULE_INFO".
>>
>> Incase lpar migrate from one system to another, system
>> parameter details like chips per sockets or number of sockets might
>> change. So, it needs to be re-initialized otherwise, these values
>> corresponds to previous system values.
>> This patch adds a call to 'read_sys_info_pseries()' from
>> 'post-mobility_fixup()' to re-init the physsockets and physchips values.
>>
>> Signed-off-by: Kajol Jain 
>> ---
>>  arch/powerpc/platforms/pseries/mobility.c | 12 
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/powerpc/platforms/pseries/mobility.c 
>> b/arch/powerpc/platforms/pseries/mobility.c
>> index b571285f6c14..226accd6218b 100644
>> --- a/arch/powerpc/platforms/pseries/mobility.c
>> +++ b/arch/powerpc/platforms/pseries/mobility.c
>> @@ -371,6 +371,18 @@ void post_mobility_fixup(void)
>>  /* Possibly switch to a new RFI flush type */
>>  pseries_setup_rfi_flush();
>>  
>> +/*
>> + * Incase lpar migrate from one system to another, system
> 
> In case an LPAR migrates
> 
>> + * parameter details like chips per sockets and number of sockets
>> + * might change. So, it needs to be re-initialized otherwise these
>  ^   ^
>  they need   the
>> + * values corresponds to previous system.
>   ^
>   will correspond to the
> 
>> + * Here, adding a call to read_sys_info_pseries() declared in
> 
> Adding is the wrong tense in a comment. When someone reads the comment
> the code has already been added. Past tense would be right, but really
> the comment shouldn't say what you did, it should say why.
> 
>> + * platforms/pseries/pseries.h to re-init the physsockets and
>> + * physchips value.
> 
> Call read_sys_info_pseries() to reinitialise the values.
> 
>> + */
>> +if (IS_ENABLED(CONFIG_HV_PERF_CTRS) && IS_ENABLED(CONFIG_PPC_RTAS))
>> +read_sys_info_pseries();
> 
> The RTAS check is not needed. pseries always selects RTAS.
> 
> You shouldn't need the IS_ENABLED() check here though, do it with an
> empty version in the header when CONFIG_HV_PERF_CTRS is not enabled.
> 

Hi Michael,
Thanks for reviewing the patch. Is something like this you are 
suggesting. Please
let me know if my understanding is fine.

+#ifndef CONFIG_HV_PERF_CTRS
+#define read_sys_info_pseries() 
+#endif

Thanks,
Kajol Jain
> cheers
> 


Re: [PATCH v4 06/12] perf expr: parse numbers as doubles

2020-05-04 Thread kajoljain



On 5/1/20 11:03 PM, Ian Rogers wrote:
> This is expected in expr.y and metrics use floating point values such as
> x86 broadwell IFetch_Line_Utilization.
> 
> Fixes: 26226a97724d (perf expr: Move expr lexer to flex)
> Signed-off-by: Ian Rogers 
> ---
>  tools/perf/util/expr.l | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/tools/perf/util/expr.l b/tools/perf/util/expr.l
> index 73db6a9ef97e..ceab11bea6f9 100644
> --- a/tools/perf/util/expr.l
> +++ b/tools/perf/util/expr.l
> @@ -10,12 +10,12 @@
>  char *expr_get_text(yyscan_t yyscanner);
>  YYSTYPE *expr_get_lval(yyscan_t yyscanner);
>  
> -static int __value(YYSTYPE *yylval, char *str, int base, int token)
> +static double __value(YYSTYPE *yylval, char *str, int token)
>  {
> - u64 num;
> + double num;
>  
>   errno = 0;
> - num = strtoull(str, NULL, base);
> + num = strtod(str, NULL);
>   if (errno)
>   return EXPR_ERROR;
>  
> @@ -23,12 +23,12 @@ static int __value(YYSTYPE *yylval, char *str, int base, 
> int token)
>   return token;
>  }
>  
> -static int value(yyscan_t scanner, int base)
> +static int value(yyscan_t scanner)
>  {
>   YYSTYPE *yylval = expr_get_lval(scanner);
>   char *text = expr_get_text(scanner);
>  
> - return __value(yylval, text, base, NUMBER);
> + return __value(yylval, text, NUMBER);
>  }
>  
>  /*
> @@ -81,7 +81,7 @@ static int str(yyscan_t scanner, int token, int runtime)
>  }
>  %}
>  
> -number   [0-9]+
> +number   [0-9]*\.?[0-9]+
>  
Acked and Tested by: Kajol Jain 
>  sch  [-,=]
>  spec \\{sch}
> @@ -105,7 +105,7 @@ min   { return MIN; }
>  if   { return IF; }
>  else { return ELSE; }
>  #smt_on  { return SMT_ON; }
> -{number} { return value(yyscanner, 10); }
> +{number} { return value(yyscanner); }
>  {symbol} { return str(yyscanner, ID, sctx->runtime); }
>  "|"  { return '|'; }
>  "^"  { return '^'; }
> 


Re: [PATCH v4 01/12] perf expr: unlimited escaped characters in a symbol

2020-05-04 Thread kajoljain



On 5/1/20 11:03 PM, Ian Rogers wrote:
> Current expression allows 2 escaped '-,=' characters. However, some
> metrics require more, for example Haswell DRAM_BW_Use.
> 
> Fixes: 26226a97724d (perf expr: Move expr lexer to flex)
> Signed-off-by: Ian Rogers 
> ---
>  tools/perf/util/expr.l | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/perf/util/expr.l b/tools/perf/util/expr.l
> index 74b9b59b1aa5..73db6a9ef97e 100644
> --- a/tools/perf/util/expr.l
> +++ b/tools/perf/util/expr.l
> @@ -86,7 +86,7 @@ number  [0-9]+
>  sch  [-,=]
>  spec \\{sch}
>  sym  [0-9a-zA-Z_\.:@?]+
> -symbol   {spec}*{sym}*{spec}*{sym}*{spec}*{sym}
> +symbol   ({spec}|{sym})+

Acked and Tested By: Kajol Jain 
>  
>  %%
>   struct expr_scanner_ctx *sctx = expr_get_extra(yyscanner);
> 


Re: [PATCHv2 0/3] perf tools: Add support for user defined metric

2020-04-30 Thread kajoljain



On 4/21/20 11:43 PM, Jiri Olsa wrote:
> hi,
> Joe asked for possibility to add user defined metrics. Given that
> we already have metrics support, I added --metrics-file option that
> allows to specify custom metrics.
> 
>   $ cat metrics
>   # IPC
>   mine1 = instructions / cycles;
>   /* DECODED_ICACHE_UOPS% */
>   mine2 = 100 * (idq.dsb_uops / \ (idq.ms_uops + idq.mite_uops + idq.dsb_uops 
> + lsd.uops));
> 
>   $ sudo perf stat --metrics-file ./metrics -M mine1,mine2 --metric-only -a 
> -I 1000
>   #   time   insn per cyclemine1
> mine2
>1.0005362630.71   0.7 
> 41.4
>2.0020690250.31   0.3 
> 14.1
>3.0034276840.27   0.3 
> 14.8
>4.0048071320.25   0.2 
> 12.1
>   ...
> 
> v2 changes:
>   - add new --metrics-file option
>   - rebased on current perf/core expression bison/flex enhancements
> 
> Also available in:
>   git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
>   perf/metric
> 
> thanks,
> jirka
> 
> 
> ---
> Jiri Olsa (3):
>   perf expr: Add parsing support for multiple expressions
>   perf expr: Allow comments in custom metric file
>   perf stat: Add --metrics-file option

Hi Jiri,
 I try to look into these patches. As far as I understand we are using
syntax "Name: Expression" for user defined events. It will be great if we 
mention
this format somewhere for users.

Otherwise it works fine for me. Try by testing it for different metric 
expressions.
But still curious about reason for adding this support. Isn't json file is 
there for same purpose?

Thanks,
Kajol Jain
> 
>  tools/perf/Documentation/perf-stat.txt |  3 +++
>  tools/perf/builtin-stat.c  |  7 +--
>  tools/perf/tests/expr.c| 13 +
>  tools/perf/util/expr.c |  6 ++
>  tools/perf/util/expr.h | 19 +--
>  tools/perf/util/expr.l | 24 
>  tools/perf/util/expr.y | 13 -
>  tools/perf/util/metricgroup.c  | 66 
> +++---
>  tools/perf/util/metricgroup.h  |  3 ++-
>  tools/perf/util/stat.h |  1 +
>  10 files changed, 142 insertions(+), 13 deletions(-)
> 


  1   2   >