NVDIMM Device and Persistent Memory development
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Kajol Jain <kjain@linux.ibm.com>,
	linuxppc-dev@lists.ozlabs.org, vaibhav@linux.ibm.com
Cc: dan.j.williams@intel.com, nvdimm@lists.linux.dev,
	atrajeev@linux.vnet.ibm.com, rnsastry@linux.ibm.com,
	maddy@linux.ibm.com, kjain@linux.ibm.com,
	disgoel@linux.vnet.ibm.com,
	"Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>
Subject: Re: [PATCH] powerpc/papr_scm: Fix nvdimm event mappings
Date: Mon, 27 Jun 2022 16:35:41 +1000	[thread overview]
Message-ID: <87ilom4nr6.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <20220610133431.410514-1-kjain@linux.ibm.com>

Hi Kajol,

A few comments below ...

Kajol Jain <kjain@linux.ibm.com> writes:
> Commit 4c08d4bbc089 ("powerpc/papr_scm: Add perf interface support")
> adds performance monitoring support for papr-scm nvdimm devices via
  ^ 
We're talking about a commit that's already happened so we should use
past tense, so "added".

> perf interface. It also adds one array in papr_scm_priv
                         "added" 
> structure called "nvdimm_events_map", to dynamically save the stat_id
> for events specified in nvdimm driver code "nd_perf.c".
>
> Right now the mapping is done based on the result of 
> H_SCM_PERFORMANCE_STATS hcall, when all the stats are
> requested. Currently there is an assumption, that a
> certain stat will always be found at a specific offset
> in the stat buffer.
                    ^
                    "returned by the hypervisor."

To make it clear where the stat buffer comes from, and that it's out of
our control.

> The assumption may not be true or documented as part of PAPR
> documentation.

That reads as the assumption "may not be documented as part of PAPR". I
think what you mean is the assumption *is not* documented by PAPR, and
although it happens to be true on current systems it may not be true in
future.

> Fixing it, by adding a static mapping for nvdimm events to
  Fix  it
> corresponding stat-id, and removing the map from
> papr_scm_priv structure.
>
> Fixes: 4c08d4bbc089 ("powerpc/papr_scm: Add perf interface support")
> Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
> ---
>  arch/powerpc/platforms/pseries/papr_scm.c | 59 ++++++++++-------------
>  1 file changed, 25 insertions(+), 34 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
> index 181b855b3050..5434c654a797 100644
> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> @@ -350,6 +347,26 @@ static ssize_t drc_pmem_query_stats(struct papr_scm_priv *p,
>  #ifdef CONFIG_PERF_EVENTS
>  #define to_nvdimm_pmu(_pmu)	container_of(_pmu, struct nvdimm_pmu, pmu)
> 
> +static const char * const nvdimm_events_map[] = {
> +	"N/A",
> +	"CtlResCt",
> +	"CtlResTm",
> +	"PonSecs ",
> +	"MemLife ",
> +	"CritRscU",
> +	"HostLCnt",
> +	"HostSCnt",
> +	"HostSDur",
> +	"HostLDur",
> +	"MedRCnt ",
> +	"MedWCnt ",
> +	"MedRDur ",
> +	"MedWDur ",
> +	"CchRHCnt",
> +	"CchWHCnt",
> +	"FastWCnt",
> +};
  
The order of the strings in that array becomes ABI. Because it defines
the mapping from perf_event.attr.config (perf user ABI) to the actual
event we request from the hypervisor.

So I'd like that made more explicit by using designated initialisers, eg:

static const char * const nvdimm_events_map[] = {
	[1] = "CtlResCt",
	[2] = "CtlResTm",
        ...

That way an accidental reordering of the array won't break anything.

You shouldn't need to specify 0 either as it's not used.

> @@ -370,7 +387,7 @@ static int papr_scm_pmu_get_value(struct perf_event *event, struct device *dev,
>  
>  	stat = &stats->scm_statistic[0];
>  	memcpy(&stat->stat_id,
> -	       &p->nvdimm_events_map[event->attr.config * sizeof(stat->stat_id)],
> +	       nvdimm_events_map[event->attr.config],
>  		sizeof(stat->stat_id));

It's not clear that this won't index off the end of the array.

There is a check in papr_scm_pmu_event_init(), but I'd probably be
happier if we did an explicit check in here as well, eg:

	if (event->attr.config >= ARRAY_SIZE(nvdimm_events_map))
		return -EINVAL;


>  	stat->stat_val = 0;
>  
> @@ -460,10 +477,9 @@ static void papr_scm_pmu_del(struct perf_event *event, int flags)
>  
>  static int papr_scm_pmu_check_events(struct papr_scm_priv *p, struct nvdimm_pmu *nd_pmu)
>  {
> -	struct papr_scm_perf_stat *stat;
>  	struct papr_scm_perf_stats *stats;
>  	u32 available_events;
> -	int index, rc = 0;
> +	int rc = 0;

You shouldn't need to initialise rc here. It's not used until the call
to drc_pmem_query_stats() below.

>  	available_events = (p->stat_buffer_len  - sizeof(struct papr_scm_perf_stats))
>  			/ sizeof(struct papr_scm_perf_stat);
> @@ -473,34 +489,12 @@ static int papr_scm_pmu_check_events(struct papr_scm_priv *p, struct nvdimm_pmu
>  	/* Allocate the buffer for phyp where stats are written */
>  	stats = kzalloc(p->stat_buffer_len, GFP_KERNEL);
>  	if (!stats) {
> -		rc = -ENOMEM;
> -		return rc;
> +		return -ENOMEM;
>  	}
>  
>  	/* Called to get list of events supported */
>  	rc = drc_pmem_query_stats(p, stats, 0);
> -	if (rc)
> -		goto out;
>  
> -	/*
> -	 * Allocate memory and populate nvdimm_event_map.
> -	 * Allocate an extra element for NULL entry
> -	 */
> -	p->nvdimm_events_map = kcalloc(available_events + 1,
> -				       sizeof(stat->stat_id),
> -				       GFP_KERNEL);
> -	if (!p->nvdimm_events_map) {
> -		rc = -ENOMEM;
> -		goto out;
> -	}
> -
> -	/* Copy all stat_ids to event map */
> -	for (index = 0, stat = stats->scm_statistic;
> -	     index < available_events; index++, ++stat) {
> -		memcpy(&p->nvdimm_events_map[index * sizeof(stat->stat_id)],
> -		       &stat->stat_id, sizeof(stat->stat_id));
> -	}
> -out:
>  	kfree(stats);
>  	return rc;
>  }

cheers

  reply	other threads:[~2022-06-27  6:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-10 13:34 [PATCH] powerpc/papr_scm: Fix nvdimm event mappings Kajol Jain
2022-06-27  6:35 ` Michael Ellerman [this message]
2022-06-28  6:04   ` kajoljain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ilom4nr6.fsf@mpe.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=atrajeev@linux.vnet.ibm.com \
    --cc=dan.j.williams@intel.com \
    --cc=disgoel@linux.vnet.ibm.com \
    --cc=kjain@linux.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=nvdimm@lists.linux.dev \
    --cc=rnsastry@linux.ibm.com \
    --cc=vaibhav@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox