All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vaibhav Jain <vaibhav@linux.ibm.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-nvdimm <linux-nvdimm@lists.01.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
	Alastair D'Silva <alastair@d-silva.org>
Subject: Re: Feedback requested: Exposing NVDIMM performance statistics in a generic way
Date: Fri, 29 May 2020 00:29:04 +0530	[thread overview]
Message-ID: <87r1v3lwcn.fsf@linux.ibm.com> (raw)
In-Reply-To: <CAPcyv4iTNK1ixzBRkm=09mHfrWzmd97HE4v-M2K5Uz0cKKT=3Q@mail.gmail.com>

Thanks for this taking time to look into this Dan,

Agree with the points you have made earlier that I am summarizing below:

* This is better done in ndctl rather than ipmctl.
* Should only expose general performance metrics and not performance
  counters. Performance counter should be exposed via perf
* Vendor specific metrics to be separated from generic performance
  metrics.

One way to split generic and vendor specific metrics might be to report
generic performance metrics together with dimm health metrics such as
"temprature_celsius" or "spares_percentage" that are already reported in
by dimm health output.

Vendor specific performance metrics can be reported as a seperate object
in the json output. Something similar to output below:

# ndctl list -DH --stats --vendor-stats
[
  {
    "dev":"nmem0",
    "health":{
      "health_state":"ok",
      "shutdown_state":"clean",
      "temperature_celsius":48.00,
      "spares_percentage":10,

      /* Generic performance metrics/stats */
      "TotalMediaReads": 18929,
      "TotalMediaWrites": 0,
      ....
    }
    
    /* Vendor specific stats for the dimm */
    "vendor-stats": {
    "Controller Reset Count":10
    "Controller Reset Elapsed Time": 3600
    "Power-on Seconds": 3600
    }
  }
]


Dan Williams <dan.j.williams@intel.com> writes:

> On Wed, May 27, 2020 at 12:24 PM Dan Williams <dan.j.williams@intel.com> wrote:
> [..]
>> > This was done by adding two new dimm-ops callbacks that were
>> > implemented by the papr_scm implementation within libndctl. These
>> > callbacks are invoked by newly introduce code in 'util/json-smart.c'
>> > that format the returned stats from these new dimm-ops and transform
>> > them into a json-object to later presentation. I would request you to
>> > look at RFC patch-set[2] to understand the implementation details.
>>
>> I'm ok to add some stats to ndctl, but I want ndctl to be limited to
>> general statistics and not performance counters. Performance counters
>> and performance events should be abstracted through perf where
>> possible.
>
> Another aspect that helps common statistics is to expose them in
> sysfs. I'm going to go review your proposed ioctl mechanism, but I
> would hope that is reserved for multi-field command payloads that need
> to be sent as a unit rather than statistics retrieval that is amenable
> to a sysfs interface.

The patchset is using a machenism similar to GET_CONFIG_SIZE/DATA to
retrive a struct composed of tuples of (stat-id, stat-value) from
papr_scm and then exposes them to ndctl via some new dimm-ops.

-- 
Cheers
~ Vaibhav
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

  reply	other threads:[~2020-05-28 18:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-25  9:00 Feedback requested: Exposing NVDIMM performance statistics in a generic way Vaibhav Jain
2020-05-27 19:24 ` Dan Williams
2020-05-28  0:55   ` Dan Williams
2020-05-28 18:59     ` Vaibhav Jain [this message]
2020-05-28 22:40       ` Dan Williams
2020-10-23 17:28       ` Michal Suchánek
2020-10-23 19:03         ` Dan Williams
2020-11-23  7:21           ` Vaibhav Jain

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=87r1v3lwcn.fsf@linux.ibm.com \
    --to=vaibhav@linux.ibm.com \
    --cc=alastair@d-silva.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=dan.j.williams@intel.com \
    --cc=linux-nvdimm@lists.01.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.