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?

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.

> 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

> 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.

On Sun, Jul 23, 2017 at 10:50 PM, Yasunori Goto <y-goto(a)jp.fujitsu.com&gt; 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.

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.

On Wed, Aug 9, 2017 at 7:19 AM, Jeff Moyer <jmoyer(a)redhat.com&gt; wrote: > Yasunori Goto <y-goto(a)jp.fujitsu.com&gt; 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(a)lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm

>>>> >>>>>> 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.

On Sun, Jul 2, 2017 at 9:53 PM, Yasunori Goto <y-goto(a)jp.fujitsu.com&gt; 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.