You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, it states that LTTng supports NVRAM, which is inaccurate. First, a bit of context:
The integration of LTTng-UST with DAX/PMEM has never targeted PMEM based on NVRAM, but rather uses a less known capability of PMEM which is to map an area of Volatile memory (RAM). So as long as the user can guarantee that this area of memory is not cleared on warm-reboot (either through BIOS guarantee, or by using kexec() to boot into another kernel from a watchdog), we get access to the DAX filesystem content after reboot.
Saying that this feature targets NVRAM misleads end users, because they would believe that they need niche NVRAM hardware such as Intel Optane (now discontinued) to use the feature when in fact they can use it on pretty much any commodity hardware over normal RAM.
We should also document how to configure pmem/dax in that section, so people can specifically see how we configure things so it works over normal RAM. Pointing to the pmem/dax documentation does not do us service here because that documentation is mainly targeting NVRAM use-cases, which is not ours.
If we ever intend to improve LTTng to make it really support NVRAM, then we would need integration with things like libpmem (https://pmem.io/pmdk/libpmem/) and add pmem_persist() calls after recording each event. This issues additional instructions on the CPU which guarantee that the content of the cache has been flushed to NVRAM, thus making sure the trace data would be available after pulling the power from the computer. This is NOT something we currently guarantee, and it would not be entirely free performance-wise, so I would not invest effort in this unless we have real-life end users showing interest for this.
The text was updated successfully, but these errors were encountered:
This section has a few issues: https://lttng.org/docs/v2.13/#doc-persistent-memory-file-systems
First, it states that LTTng supports NVRAM, which is inaccurate. First, a bit of context:
The integration of LTTng-UST with DAX/PMEM has never targeted PMEM based on NVRAM, but rather uses a less known capability of PMEM which is to map an area of Volatile memory (RAM). So as long as the user can guarantee that this area of memory is not cleared on warm-reboot (either through BIOS guarantee, or by using kexec() to boot into another kernel from a watchdog), we get access to the DAX filesystem content after reboot.
Saying that this feature targets NVRAM misleads end users, because they would believe that they need niche NVRAM hardware such as Intel Optane (now discontinued) to use the feature when in fact they can use it on pretty much any commodity hardware over normal RAM.
We should also document how to configure pmem/dax in that section, so people can specifically see how we configure things so it works over normal RAM. Pointing to the pmem/dax documentation does not do us service here because that documentation is mainly targeting NVRAM use-cases, which is not ours.
If we ever intend to improve LTTng to make it really support NVRAM, then we would need integration with things like libpmem (https://pmem.io/pmdk/libpmem/) and add pmem_persist() calls after recording each event. This issues additional instructions on the CPU which guarantee that the content of the cache has been flushed to NVRAM, thus making sure the trace data would be available after pulling the power from the computer. This is NOT something we currently guarantee, and it would not be entirely free performance-wise, so I would not invest effort in this unless we have real-life end users showing interest for this.
The text was updated successfully, but these errors were encountered: