Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify LTTng documentation "persistent memory" section #44

Open
compudj opened this issue Feb 2, 2024 · 0 comments
Open

Clarify LTTng documentation "persistent memory" section #44

compudj opened this issue Feb 2, 2024 · 0 comments

Comments

@compudj
Copy link

compudj commented Feb 2, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant