Standardization of ACPI NVDIMM DSMs

Standardization of ACPI NVDIMM DSMs

[Rebecca Cran]

I'm pretty new to ACPI work so it's possibly I'm misunderstanding
something. I've recently started working on NVDIMMs, and have
noticed that both HPE and Intel have DSM "Example" interfaces that are
referenced/used in Linux. I've been wondering if there's a reason
the content from both couldn't be combined and added to the ACPI
specification with sufficient vendor-specific fields to support the
cases where they need to differ?

-- 
Rebecca Cran
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: Standardization of ACPI NVDIMM DSMs

[Linda Knippers]

On 6/28/2017 11:40 AM, Rebecca Cran wrote:
> I'm pretty new to ACPI work so it's possibly I'm misunderstanding
> something. I've recently started working on NVDIMMs, and have
> noticed that both HPE and Intel have DSM "Example" interfaces that are
> referenced/used in Linux. I've been wondering if there's a reason
> the content from both couldn't be combined and added to the ACPI
> specification with sufficient vendor-specific fields to support the
> cases where they need to differ?

Hi Rebecca,

The main reason that there are multiple specifications, including
yet another from Microsoft, is that different hardware is evolving
in parallel and there are some different needs.  However, there is
a big effort to standardize as much as possible.  If you compare
ACPI 6.1 to ACPI 6.2, you can see new root device DSMs as well as
standard methods for reading/writing label space.  These replace
what were previously vendor-specific functions.

There is more standardization that will likely happen.  The most
interesting is probably standard health status information.  Today
the Linux ndctl command can display health status for the NVDIMMs
and it hides some of the differences by calling the appropriate
DSM for the platform/NVDIMM combination but we need to do more
work there.

Does this help?

-- ljk
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: Standardization of ACPI NVDIMM DSMs

[Rebecca Cran]

On Wed, 28 Jun 2017 11:59:04 -0400
Linda Knippers <linda.knippers@hpe.com> wrote:

> There is more standardization that will likely happen.  The most
> interesting is probably standard health status information.  Today
> the Linux ndctl command can display health status for the NVDIMMs
> and it hides some of the differences by calling the appropriate
> DSM for the platform/NVDIMM combination but we need to do more
> work there.
> 
> Does this help?

Thanks, that's perfect! I will continue working on the proposal to add
SMART/Health data into ACPI in that case, since it _does_ look like
there's sufficient commonality that standardization should be
relatively easy. I'm really working on an NVDIMM-P product, but it will
be applicable to NVDIMM-N modules too.

-- 
Rebecca Cran
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: Standardization of ACPI NVDIMM DSMs

[Yasunori Goto]

Hello, Linda-san,

> There is more standardization that will likely happen.  The most
> interesting is probably standard health status information.  Today
> the Linux ndctl command can display health status for the NVDIMMs
> and it hides some of the differences by calling the appropriate
> DSM for the platform/NVDIMM combination but we need to do more
> work there.

Could you tell me what works are necessary?

I also have concern around here, and I'm investgating source code of 
ndctl and NVDIMM drivers to check what works are still needed.
So, your opinion will be very helpful for me.

Thanks.


_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: Standardization of ACPI NVDIMM DSMs

[Linda Knippers]

On 6/29/2017 9:18 PM, Yasunori Goto wrote:
> Hello, Linda-san,
>
>> There is more standardization that will likely happen.  The most
>> interesting is probably standard health status information.  Today
>> the Linux ndctl command can display health status for the NVDIMMs
>> and it hides some of the differences by calling the appropriate
>> DSM for the platform/NVDIMM combination but we need to do more
>> work there.
>
> Could you tell me what works are necessary?

There is work in two areas.  One is standardization work, mostly
likely through the ACPI NVM working group of the UEFI Forum, to define
some common functions for health information.  There was a lot of work
focused on getting standardization of label formats and access
methods into ACPI 6.2 and UEFI 2.7 so not much effort yet on
health information but perhaps that will be next.

The other area is work within the ndctl tool itself.  It already
knows how to get some health information using the Intel, HPE, and
MSFT SMART health DSMs but there is more information related to
NVDIMM-N devices that we'd like to expose.

> I also have concern around here, and I'm investgating source code of
> ndctl and NVDIMM drivers to check what works are still needed.
> So, your opinion will be very helpful for me.

As an example, this is a patch I posted to expose more information.
https://lists.01.org/pipermail/linux-nvdimm/2017-June/010682.html
Dan had some feedback but I haven't had a chance to post a v2 patch yet.
The patch touches a number of files/functions that are involved in getting
the health information so you could look at those to see how it works today.

If there is a particular type of NVDIMM or existing DSM specification
that you're interesting in supporting, that would be interesting to know.
If you're thinking of defining something new, I encourage you to get
involved in the standards activities.

Thanks,

-- ljk

>
> Thanks.
>
>
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: Standardization of ACPI NVDIMM DSMs

[Yasunori Goto]

> On 6/29/2017 9:18 PM, Yasunori Goto wrote:
> > Hello, Linda-san,
> >
> >> There is more standardization that will likely happen.  The most
> >> interesting is probably standard health status information.  Today
> >> the Linux ndctl command can display health status for the NVDIMMs
> >> and it hides some of the differences by calling the appropriate
> >> DSM for the platform/NVDIMM combination but we need to do more
> >> work there.
> >
> > Could you tell me what works are necessary?
> 
> There is work in two areas.  One is standardization work, mostly
> likely through the ACPI NVM working group of the UEFI Forum, to define
> some common functions for health information.  There was a lot of work
> focused on getting standardization of label formats and access
> methods into ACPI 6.2 and UEFI 2.7 so not much effort yet on
> health information but perhaps that will be next.
> 
> The other area is work within the ndctl tool itself.  It already
> knows how to get some health information using the Intel, HPE, and
> MSFT SMART health DSMs but there is more information related to
> NVDIMM-N devices that we'd like to expose.
> 
> > I also have concern around here, and I'm investgating source code of
> > ndctl and NVDIMM drivers to check what works are still needed.
> > So, your opinion will be very helpful for me.
> 
> As an example, this is a patch I posted to expose more information.
> https://lists.01.org/pipermail/linux-nvdimm/2017-June/010682.html
> Dan had some feedback but I haven't had a chance to post a v2 patch yet.
> The patch touches a number of files/functions that are involved in getting
> the health information so you could look at those to see how it works today.

Thank you for your explanation. 

> 
> If there is a particular type of NVDIMM or existing DSM specification
> that you're interesting in supporting, that would be interesting to know.

Currently,  I feel the following things about _DSM and ndctl from user's point of view.

1) Though current _DSM has only the feature to get each threshold values, 
    I suppose that users may want to change each threshold values according to
     their own policy. So, maybe _DSM need to have "set threshold" interface.

2) I suppose a notification daemon may be necessary to inform the over
    threshold event  (to syslog, to other servers, or logging management OSS, etc....)

    Please correct me, if ndctl has this feature already...

> If you're thinking of defining something new, I encourage you to get
> involved in the standards activities.

If my idea is useful like the aboves, the standard activity looks quite interesting 
for me. Please tell me how to join it.

Thanks,
---
Yasunori Goto

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: Standardization of ACPI NVDIMM DSMs

[Linda Knippers]

On 7/3/2017 12:53 AM, Yasunori Goto wrote:
>
>> On 6/29/2017 9:18 PM, Yasunori Goto wrote:
>>> Hello, Linda-san,
>>>
>>>> There is more standardization that will likely happen.  The most
>>>> interesting is probably standard health status information.  Today
>>>> the Linux ndctl command can display health status for the NVDIMMs
>>>> and it hides some of the differences by calling the appropriate
>>>> DSM for the platform/NVDIMM combination but we need to do more
>>>> work there.
>>>
>>> Could you tell me what works are necessary?
>>
>> There is work in two areas.  One is standardization work, mostly
>> likely through the ACPI NVM working group of the UEFI Forum, to define
>> some common functions for health information.  There was a lot of work
>> focused on getting standardization of label formats and access
>> methods into ACPI 6.2 and UEFI 2.7 so not much effort yet on
>> health information but perhaps that will be next.
>>
>> The other area is work within the ndctl tool itself.  It already
>> knows how to get some health information using the Intel, HPE, and
>> MSFT SMART health DSMs but there is more information related to
>> NVDIMM-N devices that we'd like to expose.
>>
>>> I also have concern around here, and I'm investgating source code of
>>> ndctl and NVDIMM drivers to check what works are still needed.
>>> So, your opinion will be very helpful for me.
>>
>> As an example, this is a patch I posted to expose more information.
>> https://lists.01.org/pipermail/linux-nvdimm/2017-June/010682.html
>> Dan had some feedback but I haven't had a chance to post a v2 patch yet.
>> The patch touches a number of files/functions that are involved in getting
>> the health information so you could look at those to see how it works today.
>
> Thank you for your explanation.
>
>>
>> If there is a particular type of NVDIMM or existing DSM specification
>> that you're interesting in supporting, that would be interesting to know.
>
> Currently,  I feel the following things about _DSM and ndctl from user's point of view.
>
> 1) Though current _DSM has only the feature to get each threshold values,
>     I suppose that users may want to change each threshold values according to
>      their own policy. So, maybe _DSM need to have "set threshold" interface.

That's a good question. Right now ndctl doesn't do that.  It is more focused on
managing how Linux uses the devices than managing the devices themselves,
although there is some overlap because ndctl can manipulate namespace 
information that resides on some devices.  I don't know what Dan has in mind
for the future of ndctl or whether he'd entertain patches in this area.

> 2) I suppose a notification daemon may be necessary to inform the over
>     threshold event  (to syslog, to other servers, or logging management OSS, etc....)
>
>     Please correct me, if ndctl has this feature already...

That feature doesn't exist in ndctl.  Intel has developed some tools that are 
mostly specific to their NVDIMMs and those tools include a monitoring daemon as
well as a CLI.
https://github.com/01org/ixpdimm_sw

One approach could be to contribute changes to make those tools more useful for 
non-Intel NVDIMMs.  Another approach could be to integrate NVDIMM event
monitoring into some other utility, like the rasdaemon.  I'm interested in
your thoughts.

>> If you're thinking of defining something new, I encourage you to get
>> involved in the standards activities.
>
> If my idea is useful like the aboves, the standard activity looks quite interesting
> for me. Please tell me how to join it.

If your company is part of the UEFI Forum then I think you can participate in
the ACPI working group.  There is a sub-team focused on standardizing NVDIMM
FW/SW interfaces.  My suggestion is that you find the person in your company
who can hook you up with the right group.

You'll also see conversation/debate about what ought to be a standard
on this mailing list so input here is welcome too.

-- ljk
>
> Thanks,
> ---
> Yasunori Goto
>
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: Standardization of ACPI NVDIMM DSMs

[Dan Williams]

On Sun, Jul 2, 2017 at 9:53 PM, Yasunori Goto <y-goto@jp.fujitsu.com> wrote:
[..]
> 2) I suppose a notification daemon may be necessary to inform the over
>     threshold event  (to syslog, to other servers, or logging management OSS, etc....)
>
>     Please correct me, if ndctl has this feature already...

ndctl doesn't have a daemon yet, but libndctl is growing helper
library calls that would used for such a daemon one day.

ndctl_dimm_get_health_eventfd() is there today provides a file
descriptor for DIMM events, and I'll be adding similar eventfd calls
for the region and namespace level badblocks files so userspace is
notified of new media errors.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: Standardization of ACPI NVDIMM DSMs

[Yasunori Goto]

> > 2) I suppose a notification daemon may be necessary to inform the over
> >     threshold event  (to syslog, to other servers, or logging management OSS, etc....)
> >
> >     Please correct me, if ndctl has this feature already...
> 
> That feature doesn't exist in ndctl.  Intel has developed some tools that are
> mostly specific to their NVDIMMs and those tools include a monitoring daemon as
> well as a CLI.
> https://github.com/01org/ixpdimm_sw

Though I tried to compile this tools, I could not comple it, and 
I gave up to solve too many dependency... 

> 
> One approach could be to contribute changes to make those tools more useful for non-Intel NVDIMMs.

Hmmm, ixpdimm_sw seems to be too large software.
In my first impression, I don't think this is good way..... :(

>   Another approach could be to integrate NVDIMM event
> monitoring into some other utility, like the rasdaemon.  I'm interested in
> your thoughts.

Though I'm not sure which (existing or new) utility is appropriate yet.
I prefer this way. So, I'll think about it.

> 
> >> If you're thinking of defining something new, I encourage you to get
> >> involved in the standards activities.
> >
> > If my idea is useful like the aboves, the standard activity looks quite interesting
> > for me. Please tell me how to join it.
> 
> If your company is part of the UEFI Forum then I think you can participate in
> the ACPI working group.  There is a sub-team focused on standardizing NVDIMM
> FW/SW interfaces.  My suggestion is that you find the person in your company
> who can hook you up with the right group.

Ok, I'll try to find the contact person in my company.

> 
> You'll also see conversation/debate about what ought to be a standard
> on this mailing list so input here is welcome too.

I see.
Thank you for your information.

Bye,
---
Yasunori Goto


_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: Standardization of ACPI NVDIMM DSMs

[Yasunori Goto]

> On Sun, Jul 2, 2017 at 9:53 PM, Yasunori Goto <y-goto@jp.fujitsu.com> wrote:
> [..]
> > 2) I suppose a notification daemon may be necessary to inform the over
> >     threshold event  (to syslog, to other servers, or logging management OSS, etc....)
> >
> >     Please correct me, if ndctl has this feature already...
> 
> ndctl doesn't have a daemon yet, but libndctl is growing helper
> library calls that would used for such a daemon one day.
> 
> ndctl_dimm_get_health_eventfd() is there today provides a file
> descriptor for DIMM events, and I'll be adding similar eventfd calls
> for the region and namespace level badblocks files so userspace is
> notified of new media errors.

I see. I'll check it when it is implemented.

Thanks,
---
Yasunori Goto

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Daemon of NVDIMM event notification/monitoring(Re: Standardization of ACPI NVDIMM DSMs)

[Yasunori Goto]

Hi,

> >   Another approach could be to integrate NVDIMM event
> > monitoring into some other utility, like the rasdaemon.  I'm interested in
> > your thoughts.
> 
> Though I'm not sure which (existing or new) utility is appropriate yet.
> I prefer this way. So, I'll think about it.

I investigated the issue that notification/monitoring feature of over-
threshold event with my co-worker. Here is current our understandings.


a) rasdaemon
  It is good tools for machine check error, and if machine check occurs on
  NVDIMM, I suppose it will work not only traditional RAM but also NVDIMM.
  But, it may not fit the purpose of notification/monitoring threshold event.


b) smartmontools (https://www.smartmontools.org/)
  This tool may fit the purpose of notification/monitoring of health of NVDIMMs.
  However, it may a bit troublesome due to the followings.

    - The smartd seems to check smart values of each devices with
      ioctl() periodically (In other words, "polling"). 
      Probably, other devices does not have the
      notification interface like "ndctl_dimm_get_health_eventfd()
      and poll()/select()".
      
    - smartmontools supports many OSs (Windows, darwin, xxxBSDs, os2(!)).
      I'm not sure other OSs have similar notification interface like Linux.
      So, it may need to "polling" like other devices.

c) udev
   Udev can kick any programs if udev.rules is created.
   However, there is no uevent for the event of over-threshold currently.
   In addition, I'm not sure that udev fits this type of event notification.


d) make a new tiny daemon in ndctl tree
   This may be simpler way. 
   It can use ndctl_dimm_get_health_eventfd() and poll()/select().
    
   But, ndctl may be included in kernel source,
   and I don't know whether kernel includes other daemon tools or not.


Though I feel like selecting d) now.....
Any thoughts? 


Thanks,
---
Yasunori Goto


_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: Daemon of NVDIMM event notification/monitoring(Re: Standardization of ACPI NVDIMM DSMs)

[Dan Williams]

On Sun, Jul 23, 2017 at 10:50 PM, Yasunori Goto <y-goto@jp.fujitsu.com> wrote:
>
> Hi,
>
>> >   Another approach could be to integrate NVDIMM event
>> > monitoring into some other utility, like the rasdaemon.  I'm interested in
>> > your thoughts.
>>
>> Though I'm not sure which (existing or new) utility is appropriate yet.
>> I prefer this way. So, I'll think about it.
>
> I investigated the issue that notification/monitoring feature of over-
> threshold event with my co-worker. Here is current our understandings.
>
>
> a) rasdaemon
>   It is good tools for machine check error, and if machine check occurs on
>   NVDIMM, I suppose it will work not only traditional RAM but also NVDIMM.
>   But, it may not fit the purpose of notification/monitoring threshold event.

My concern with rasdaemon is that its heuristics are built for
off-lining volatile system-ram, not managing persistent media errors.

> b) smartmontools (https://www.smartmontools.org/)
>   This tool may fit the purpose of notification/monitoring of health of NVDIMMs.
>   However, it may a bit troublesome due to the followings.
>
>     - The smartd seems to check smart values of each devices with
>       ioctl() periodically (In other words, "polling").
>       Probably, other devices does not have the
>       notification interface like "ndctl_dimm_get_health_eventfd()
>       and poll()/select()".
>
>     - smartmontools supports many OSs (Windows, darwin, xxxBSDs, os2(!)).
>       I'm not sure other OSs have similar notification interface like Linux.
>       So, it may need to "polling" like other devices.

One of the explicit goals of ndctl vs smartmontools is trying to make
sure that vendor-specific details don't leak into the output data
format. ndctl is also built to leverage the Linux specific
capabilities of the libnvdimm sub-system vs some
lowest-common-denominator implementation that results from trying to
be cross-OS compatible with an abstraction layer.

> c) udev
>    Udev can kick any programs if udev.rules is created.
>    However, there is no uevent for the event of over-threshold currently.
>    In addition, I'm not sure that udev fits this type of event notification.

There are some drivers that use uevents for logging, I prefer poll(2)
capable sysfs files.

> d) make a new tiny daemon in ndctl tree
>    This may be simpler way.
>    It can use ndctl_dimm_get_health_eventfd() and poll()/select().
>
>    But, ndctl may be included in kernel source,
>    and I don't know whether kernel includes other daemon tools or not.

The kernel does include a few daemons in the tools/ directory, so I
don't see this being a problem. Now, that said, Linus still has the
prerogative to not pull ndctl into the kernel for 4.14, but at this
point I feel more likely than not that the next version of ndctl will
be v4.14-rc1 instead of v58.

> Though I feel like selecting d) now.....
> Any thoughts?

I'm also in favor of d).
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: Daemon of NVDIMM event notification/monitoring(Re: Standardization of ACPI NVDIMM DSMs)

[Dan Williams]

On Mon, Jul 24, 2017 at 9:11 AM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Sun, Jul 23, 2017 at 10:50 PM, Yasunori Goto <y-goto@jp.fujitsu.com> wrote:
[..]
>> d) make a new tiny daemon in ndctl tree
>>    This may be simpler way.
>>    It can use ndctl_dimm_get_health_eventfd() and poll()/select().
>>
>>    But, ndctl may be included in kernel source,
>>    and I don't know whether kernel includes other daemon tools or not.
>
> The kernel does include a few daemons in the tools/ directory, so I
> don't see this being a problem. Now, that said, Linus still has the
> prerogative to not pull ndctl into the kernel for 4.14, but at this
> point I feel more likely than not that the next version of ndctl will
> be v4.14-rc1 instead of v58.

An update here... upstream would like to see ndctl move away from
autotools before it is integrated into the kernel tree, so ndctl v58
will be the next release from github. The 4.15 kernel is our next
potential intercept.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: Daemon of NVDIMM event notification/monitoring(Re: Standardization of ACPI NVDIMM DSMs)

[Christoph Hellwig]

Btw, why do you want to pull it into the kernel tree?  All the tools
in the kernel tree are a massive pain in the ass to use because it
requires a full kernel tree on every test box and VM.  Small little
repos that don't have giant churn are a lot easier to deal with.  And
also to test for compatibility issues.

They also are painful for distributions as they now have to come up
with a wrapper to pick the right tool for the right kernel version,
which have a tendency to fail if you build your own kernels.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: Daemon of NVDIMM event notification/monitoring(Re: Standardization of ACPI NVDIMM DSMs)

[Dan Williams]

On Wed, Jul 26, 2017 at 10:51 AM, Christoph Hellwig <hch@infradead.org> wrote:
> Btw, why do you want to pull it into the kernel tree?  All the tools
> in the kernel tree are a massive pain in the ass to use because it
> requires a full kernel tree on every test box and VM.  Small little
> repos that don't have giant churn are a lot easier to deal with.  And
> also to test for compatibility issues.
>
> They also are painful for distributions as they now have to come up
> with a wrapper to pick the right tool for the right kernel version,
> which have a tendency to fail if you build your own kernels.

I'm mainly motivated to get the tests closer to the test
infrastructure, and raise the profile to get more contributions from
other vendors and archs.

You're right, the requirement to have a full kernel tree to play with
the source is a pain. I think that's why we now have the "make
perf-tar-src-pkg" target so you can pass that around to test boxes and
VMs. As for compatibility there's no requirement to match ndctl to
kernel version, it's all auto-detected with fall backs for older
kernels.

However, the pain of moving away from autotools may delay this indefinitely.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: Daemon of NVDIMM event notification/monitoring(Re: Standardization of ACPI NVDIMM DSMs)

[Yasunori Goto]

> On Mon, Jul 24, 2017 at 9:11 AM, Dan Williams <dan.j.williams@intel.com> wrote:
> > On Sun, Jul 23, 2017 at 10:50 PM, Yasunori Goto <y-goto@jp.fujitsu.com> wrote:
> [..]
> >> d) make a new tiny daemon in ndctl tree
> >>    This may be simpler way.
> >>    It can use ndctl_dimm_get_health_eventfd() and poll()/select().
> >>
> >>    But, ndctl may be included in kernel source,
> >>    and I don't know whether kernel includes other daemon tools or not.
> >
> > The kernel does include a few daemons in the tools/ directory, so I
> > don't see this being a problem. Now, that said, Linus still has the
> > prerogative to not pull ndctl into the kernel for 4.14, but at this
> > point I feel more likely than not that the next version of ndctl will
> > be v4.14-rc1 instead of v58.
> 
> An update here... upstream would like to see ndctl move away from
> autotools before it is integrated into the kernel tree, so ndctl v58
> will be the next release from github. The 4.15 kernel is our next
> potential intercept.
> 

Year. Thanks for your notification.
I already asked my young co-worker to make a tiny daemon in ndctl.

Thanks,
----
Yasunori Goto


_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: Daemon of NVDIMM event notification/monitoring(Re: Standardization of ACPI NVDIMM DSMs)

[Jeff Moyer]

Yasunori Goto <y-goto@jp.fujitsu.com> writes:

> Hi,
>
>> >   Another approach could be to integrate NVDIMM event
>> > monitoring into some other utility, like the rasdaemon.  I'm interested in
>> > your thoughts.
>> 
>> Though I'm not sure which (existing or new) utility is appropriate yet.
>> I prefer this way. So, I'll think about it.
>
> I investigated the issue that notification/monitoring feature of over-
> threshold event with my co-worker. Here is current our understandings.
>
>
> a) rasdaemon
>   It is good tools for machine check error, and if machine check occurs on
>   NVDIMM, I suppose it will work not only traditional RAM but also NVDIMM.
>   But, it may not fit the purpose of notification/monitoring threshold event.
>
>
> b) smartmontools (https://www.smartmontools.org/)
>   This tool may fit the purpose of notification/monitoring of health of NVDIMMs.
>   However, it may a bit troublesome due to the followings.
>
>     - The smartd seems to check smart values of each devices with
>       ioctl() periodically (In other words, "polling"). 
>       Probably, other devices does not have the
>       notification interface like "ndctl_dimm_get_health_eventfd()
>       and poll()/select()".
>       
>     - smartmontools supports many OSs (Windows, darwin, xxxBSDs, os2(!)).
>       I'm not sure other OSs have similar notification interface like Linux.
>       So, it may need to "polling" like other devices.
>
> c) udev
>    Udev can kick any programs if udev.rules is created.
>    However, there is no uevent for the event of over-threshold currently.
>    In addition, I'm not sure that udev fits this type of event notification.
>
>
> d) make a new tiny daemon in ndctl tree
>    This may be simpler way. 
>    It can use ndctl_dimm_get_health_eventfd() and poll()/select().
>     
>    But, ndctl may be included in kernel source,
>    and I don't know whether kernel includes other daemon tools or not.

e) acpid

-Jeff
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: Daemon of NVDIMM event notification/monitoring(Re: Standardization of ACPI NVDIMM DSMs)

[Dan Williams]

On Wed, Aug 9, 2017 at 7:19 AM, Jeff Moyer <jmoyer@redhat.com> wrote:
> Yasunori Goto <y-goto@jp.fujitsu.com> writes:
>
>> Hi,
>>
>>> >   Another approach could be to integrate NVDIMM event
>>> > monitoring into some other utility, like the rasdaemon.  I'm interested in
>>> > your thoughts.
>>>
>>> Though I'm not sure which (existing or new) utility is appropriate yet.
>>> I prefer this way. So, I'll think about it.
>>
>> I investigated the issue that notification/monitoring feature of over-
>> threshold event with my co-worker. Here is current our understandings.
>>
>>
>> a) rasdaemon
>>   It is good tools for machine check error, and if machine check occurs on
>>   NVDIMM, I suppose it will work not only traditional RAM but also NVDIMM.
>>   But, it may not fit the purpose of notification/monitoring threshold event.
>>
>>
>> b) smartmontools (https://www.smartmontools.org/)
>>   This tool may fit the purpose of notification/monitoring of health of NVDIMMs.
>>   However, it may a bit troublesome due to the followings.
>>
>>     - The smartd seems to check smart values of each devices with
>>       ioctl() periodically (In other words, "polling").
>>       Probably, other devices does not have the
>>       notification interface like "ndctl_dimm_get_health_eventfd()
>>       and poll()/select()".
>>
>>     - smartmontools supports many OSs (Windows, darwin, xxxBSDs, os2(!)).
>>       I'm not sure other OSs have similar notification interface like Linux.
>>       So, it may need to "polling" like other devices.
>>
>> c) udev
>>    Udev can kick any programs if udev.rules is created.
>>    However, there is no uevent for the event of over-threshold currently.
>>    In addition, I'm not sure that udev fits this type of event notification.
>>
>>
>> d) make a new tiny daemon in ndctl tree
>>    This may be simpler way.
>>    It can use ndctl_dimm_get_health_eventfd() and poll()/select().
>>
>>    But, ndctl may be included in kernel source,
>>    and I don't know whether kernel includes other daemon tools or not.
>
> e) acpid

Except acpid is ACPI specific, and the event sources that libnvdimm
generates are generic. For example, we may be getting an Open Firmware
libnvdimm bus in the next merge window.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: Daemon of NVDIMM event notification/monitoring(Re: Standardization of ACPI NVDIMM DSMs)

[Linda Knippers]

On 08/09/2017 02:30 PM, Dan Williams wrote:
> On Wed, Aug 9, 2017 at 7:19 AM, Jeff Moyer <jmoyer@redhat.com> wrote:
>> Yasunori Goto <y-goto@jp.fujitsu.com> writes:
>>
>>> Hi,
>>>
>>>>>   Another approach could be to integrate NVDIMM event
>>>>> monitoring into some other utility, like the rasdaemon.  I'm interested in
>>>>> your thoughts.
>>>>
>>>> Though I'm not sure which (existing or new) utility is appropriate yet.
>>>> I prefer this way. So, I'll think about it.
>>>
>>> I investigated the issue that notification/monitoring feature of over-
>>> threshold event with my co-worker. Here is current our understandings.
>>>
>>>
>>> a) rasdaemon
>>>   It is good tools for machine check error, and if machine check occurs on
>>>   NVDIMM, I suppose it will work not only traditional RAM but also NVDIMM.
>>>   But, it may not fit the purpose of notification/monitoring threshold event.
>>>
>>>
>>> b) smartmontools (https://www.smartmontools.org/)
>>>   This tool may fit the purpose of notification/monitoring of health of NVDIMMs.
>>>   However, it may a bit troublesome due to the followings.
>>>
>>>     - The smartd seems to check smart values of each devices with
>>>       ioctl() periodically (In other words, "polling").
>>>       Probably, other devices does not have the
>>>       notification interface like "ndctl_dimm_get_health_eventfd()
>>>       and poll()/select()".
>>>
>>>     - smartmontools supports many OSs (Windows, darwin, xxxBSDs, os2(!)).
>>>       I'm not sure other OSs have similar notification interface like Linux.
>>>       So, it may need to "polling" like other devices.
>>>
>>> c) udev
>>>    Udev can kick any programs if udev.rules is created.
>>>    However, there is no uevent for the event of over-threshold currently.
>>>    In addition, I'm not sure that udev fits this type of event notification.
>>>
>>>
>>> d) make a new tiny daemon in ndctl tree
>>>    This may be simpler way.
>>>    It can use ndctl_dimm_get_health_eventfd() and poll()/select().
>>>
>>>    But, ndctl may be included in kernel source,
>>>    and I don't know whether kernel includes other daemon tools or not.
>>
>> e) acpid
> 
> Except acpid is ACPI specific, and the event sources that libnvdimm
> generates are generic. For example, we may be getting an Open Firmware
> libnvdimm bus in the next merge window.

Can you say more about that?  It seems that the notifications we're worried
about here and the interface for getting information about the notification
are both ACPI-specific.

We haven't talked much about iwhat a daemon would do once it gets a
notification from whatever the source is.  That might help us determine
the right tool.  Is it just logging?

-- ljk
> _______________________________________________
> Linux-nvdimm mailing list
> Linux-nvdimm@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm
> 

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: Daemon of NVDIMM event notification/monitoring(Re: Standardization of ACPI NVDIMM DSMs)

[Dan Williams]

On Wed, Aug 9, 2017 at 12:00 PM, Linda Knippers <linda.knippers@hpe.com> wrote:
> On 08/09/2017 02:30 PM, Dan Williams wrote:
>> On Wed, Aug 9, 2017 at 7:19 AM, Jeff Moyer <jmoyer@redhat.com> wrote:
>>> Yasunori Goto <y-goto@jp.fujitsu.com> writes:
>>>
>>>> Hi,
>>>>
>>>>>>   Another approach could be to integrate NVDIMM event
>>>>>> monitoring into some other utility, like the rasdaemon.  I'm interested in
>>>>>> your thoughts.
>>>>>
>>>>> Though I'm not sure which (existing or new) utility is appropriate yet.
>>>>> I prefer this way. So, I'll think about it.
>>>>
>>>> I investigated the issue that notification/monitoring feature of over-
>>>> threshold event with my co-worker. Here is current our understandings.
>>>>
>>>>
>>>> a) rasdaemon
>>>>   It is good tools for machine check error, and if machine check occurs on
>>>>   NVDIMM, I suppose it will work not only traditional RAM but also NVDIMM.
>>>>   But, it may not fit the purpose of notification/monitoring threshold event.
>>>>
>>>>
>>>> b) smartmontools (https://www.smartmontools.org/)
>>>>   This tool may fit the purpose of notification/monitoring of health of NVDIMMs.
>>>>   However, it may a bit troublesome due to the followings.
>>>>
>>>>     - The smartd seems to check smart values of each devices with
>>>>       ioctl() periodically (In other words, "polling").
>>>>       Probably, other devices does not have the
>>>>       notification interface like "ndctl_dimm_get_health_eventfd()
>>>>       and poll()/select()".
>>>>
>>>>     - smartmontools supports many OSs (Windows, darwin, xxxBSDs, os2(!)).
>>>>       I'm not sure other OSs have similar notification interface like Linux.
>>>>       So, it may need to "polling" like other devices.
>>>>
>>>> c) udev
>>>>    Udev can kick any programs if udev.rules is created.
>>>>    However, there is no uevent for the event of over-threshold currently.
>>>>    In addition, I'm not sure that udev fits this type of event notification.
>>>>
>>>>
>>>> d) make a new tiny daemon in ndctl tree
>>>>    This may be simpler way.
>>>>    It can use ndctl_dimm_get_health_eventfd() and poll()/select().
>>>>
>>>>    But, ndctl may be included in kernel source,
>>>>    and I don't know whether kernel includes other daemon tools or not.
>>>
>>> e) acpid
>>
>> Except acpid is ACPI specific, and the event sources that libnvdimm
>> generates are generic. For example, we may be getting an Open Firmware
>> libnvdimm bus in the next merge window.
>
> Can you say more about that?  It seems that the notifications we're worried
> about here and the interface for getting information about the notification
> are both ACPI-specific.

Capturing the raw acpi events is not that interesting because we'll
immediately want to turn around and ask what those mean to Linux
kernel objects, so might as well monitor those objects directly.

> We haven't talked much about iwhat a daemon would do once it gets a
> notification from whatever the source is.  That might help us determine
> the right tool.  Is it just logging?

Yes, logging, and maybe a simple framework to call external helper
applications when a given events fires, or fires too many times within
a certain threshold.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: Daemon of NVDIMM event notification/monitoring(Re: Standardization of ACPI NVDIMM DSMs)

[Yasunori Goto]

> >>>>
> >>>>>>   Another approach could be to integrate NVDIMM event
> >>>>>> monitoring into some other utility, like the rasdaemon.  I'm interested in
> >>>>>> your thoughts.
> >>>>>
> >>>>> Though I'm not sure which (existing or new) utility is appropriate yet.
> >>>>> I prefer this way. So, I'll think about it.
> >>>>
> >>>> I investigated the issue that notification/monitoring feature of over-
> >>>> threshold event with my co-worker. Here is current our understandings.
> >>>>
> >>>>
> >>>> a) rasdaemon
> >>>>   It is good tools for machine check error, and if machine check occurs on
> >>>>   NVDIMM, I suppose it will work not only traditional RAM but also NVDIMM.
> >>>>   But, it may not fit the purpose of notification/monitoring threshold event.
> >>>>
> >>>>
> >>>> b) smartmontools (https://www.smartmontools.org/)
> >>>>   This tool may fit the purpose of notification/monitoring of health of NVDIMMs.
> >>>>   However, it may a bit troublesome due to the followings.
> >>>>
> >>>>     - The smartd seems to check smart values of each devices with
> >>>>       ioctl() periodically (In other words, "polling").
> >>>>       Probably, other devices does not have the
> >>>>       notification interface like "ndctl_dimm_get_health_eventfd()
> >>>>       and poll()/select()".
> >>>>
> >>>>     - smartmontools supports many OSs (Windows, darwin, xxxBSDs, os2(!)).
> >>>>       I'm not sure other OSs have similar notification interface like Linux.
> >>>>       So, it may need to "polling" like other devices.
> >>>>
> >>>> c) udev
> >>>>    Udev can kick any programs if udev.rules is created.
> >>>>    However, there is no uevent for the event of over-threshold currently.
> >>>>    In addition, I'm not sure that udev fits this type of event notification.
> >>>>
> >>>>
> >>>> d) make a new tiny daemon in ndctl tree
> >>>>    This may be simpler way.
> >>>>    It can use ndctl_dimm_get_health_eventfd() and poll()/select().
> >>>>
> >>>>    But, ndctl may be included in kernel source,
> >>>>    and I don't know whether kernel includes other daemon tools or not.
> >>>
> >>> e) acpid
> >>
> >> Except acpid is ACPI specific, and the event sources that libnvdimm
> >> generates are generic. For example, we may be getting an Open Firmware
> >> libnvdimm bus in the next merge window.
> >
> > Can you say more about that?  It seems that the notifications we're worried
> > about here and the interface for getting information about the notification
> > are both ACPI-specific.
> 
> Capturing the raw acpi events is not that interesting because we'll
> immediately want to turn around and ask what those mean to Linux
> kernel objects, so might as well monitor those objects directly.
> 
> > We haven't talked much about iwhat a daemon would do once it gets a
> > notification from whatever the source is.  That might help us determine
> > the right tool.  Is it just logging?
> 
> Yes, logging, and maybe a simple framework to call external helper
> applications when a given events fires, or fires too many times within
> a certain threshold.

I agree.

I guess some uses would like to use Logstash, Fluentd, or any other
log monitor/collector/analyzer tools. But another users want to kick
applications to avoid serious trouble like data corruption.

Thanks,
---
Yasunori Goto



_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm