Messages in this thread | | | Date | Thu, 16 Feb 2023 18:00:51 +0100 | From | David Hildenbrand <> | Subject | Re: [PATCH] mm/uffd: UFFD_FEATURE_WP_ZEROPAGE |
| |
>> >> There are various reasons why I think a UFFD_FEATURE_WP_UNPOPULATED, using >> PTE markers, would be more benficial: >> >> 1) It would be applicable to anon hugetlb > > Anon hugetlb should already work with non ptes with the markers? >
... really? I thought we'd do the whole pte marker handling only when dealing with hugetlb/shmem. Interesting, thanks. (we could skip population in QEMU in that case as well -- we always do it for now)
>> 2) It would be applicable even when the zeropage is disallowed >> (mm_forbids_zeropage()) > > Do you mean s390 can disable zeropage with mm_uses_skeys()? So far uffd-wp > doesn't support s390 yet, I'm not sure whether we over worried on this > effect. > > Or is there any other projects / ideas that potentially can enlarge forbid > zero pages to more contexts?
I think it was shown that zeropages can be used to build covert channels (similar to memory deduplciation, because it effectively is memory deduplication). It's mentioned as a note in [1] under VII. A. ("Only Deduplicate Zero Pages.")
[1] https://www.ndss-symposium.org/wp-content/uploads/2022-81-paper.pdf
> >> 3) It would be possible to optimize even without the huge zeropage, by >> using a PMD marker. > > This patch doesn't need huge zeropage being exist.
Yes, and for that reason I think it may perform worse than what we already have in some cases. Instead of populating a single PMD you'll have to fill a full PTE table.
> >> 4) It would be possible to optimize even on the PUD level using a PMD >> marker. > > I think 3+4 is in general an interesting idea on using pte markers on > higher than pte levels, but that needs more changes. > > Firstly, keep using pte markers is somehow preallocating the pgtables, so a > side effect of it could be speeding up future faults because they'll all > split into pmd locks and read doesn't need to fault at all, only writes. > > Imagine when you hit a page fault on a pmd marker, it means you'll need to > spread that "marker" information to child ptes and you must - it moves the > slow operation of WP into future page faults in some way. In some cases > (I'd say, most cases..) that's not wanted. The same to PUDs.
Right, but user space already has that option (see below).
> >> >> Especially when uffd-wp'ing large ranges that are possibly all unpopulated >> (thinking about the existing VM background snapshot use case either with >> untouched memory or with things like free page reporting), we might neither >> be reading or writing that memory any time soon. > > Right, I think that's a trade-off. But I still think large portion of > totally unpopulated memory should be rare case rather than majority, or am > I wrong? Not to mention that requires a more involved changeset to the > kernel. > > So what I proposed here is the (AFAIU) simplest solution towards providing > such a feature in a complete form. I think we have chance to implement it > in other ways like pte markers, but that's something we can work upon, and > so far I'm not sure how much benefit we can get out of it yet. >
What you propose here can already be achieved by user space fairly easily (in fact, QEMU implementation could be further sped up using MADV_POPULATE_READ). Usually, we only do that when there are very good reasons to (performance).
Using PTE markers would provide a real advantage IMHO for some users (IMHO background snapshots), where we might want to avoid populating zeropages/page tables as best as we can completely if the VM memory is mostly untouched.
Naturally, I wonder if UFFD_FEATURE_WP_ZEROPAGE is really worth it. Is there is another good reason to combine the populate zeropage+wp that I am missing (e.g., atomicity by doing both in one operation)?
-- Thanks,
David / dhildenb
| |