I don't understand "without actually reading memory"? Do you mean,
"without actually faulting in the pages"; or something else?
"Populate (prefault) page tables readable, faulting in all pages in the
range just as if manually reading one byte of each page; however, avoid
the actual memory access that would have been performed after handling
the fault."
Does that make it clearer? (avoiding eventually touching the page at all
can be beneficial, especially when dealing with DAX memory where memory
access might be expensive)
That text is much better. But, what's still not clear to me then is the
dfference between mmap(2) MAP_POPULATE, and MADV_POPULATE_READ and
MADV_POPULATE_WRITE. What is the differnece, and in what situations
would one prefer one or the other approach? I think it would be helpful
if the manual page said something about these details.
Well, MAP_POPULATE
1. Can only be used on new mappings, not on existing mappings and
especially not on parts of (sparse) memory mappings.
2. Hides actual population errors, simply returning "success"
3. Cannot specify the actual faultin behavior (readable vs. writable).
Private mappings are always faulted in writable, shared mappings writable.
MADV_POPULATE_WRITE is the way to go to preallocate memory, especially
hugetlbfs. MADV_POPULATE_READ can be used to just populate the shared
zero page, or to fault-in file-backed memory without marking everything
dirty such that it won't have to be written back to disk.
for MADV_POPULATE_READ
"In contrast to MAP_POPULATE, MADV_POPULATE_READ does not hide errors,
can be applied to (parts of) existing mappings and will always populate
(prefault) page tables readable. One example use case is prefaulting a
file mapping, reading all file content from disk; however, pages won't
be dirtied and consequently won't have to be written back to disk when
evicting the pages from memory."
Suggestions welcome :)
for MADV_POPULATE_WRITE
"In contrast to MAP_POPULATE, MADV_POPULATE_WRITE does not hide errors,
can be applied to (parts of) existing mappings and will always populate
(prefault) page tables writable. One example use case is preallocating
memory, breaking any CoW (Copy on Write)."
Again, suggestions welcome :)
[...]
Much better. Note that there might be more types of mappings that won't
work (e.g., initially also secretmem IIRC).
Ahh nice. Since there's about to be a memfd_secret() manual page,
I suggest adding also "or secret memory regions created using
memfd_secret(2)".
Can do, thanks!
[...]
Sure, we can add that. But note that MADV_HWPOISON is just one of many
ways to HWpoison a page.
Then maybe something like:
"(HW poisoned pages can, for example, be created using the
MADV_HWPOISON flag described elsewhere in this page.)"
Makes sense, I'll reuse the same description at the other place in this
file where I mention HW poisoned pages.
--
Thanks,
David / dhildenb
