Messages in this thread | | | Date | Sat, 27 Apr 2024 08:58:26 +0200 | Subject | Re: [PATCH v1 1/3] mm/gup: consistently name GUP-fast functions | From | David Hildenbrand <> |
| |
On 26.04.24 23:58, Peter Xu wrote: > On Fri, Apr 26, 2024 at 11:33:08PM +0200, David Hildenbrand wrote: >> I raised this topic in the past, and IMHO we either (a) never should have >> added COW support; or (b) added COW support by using ordinary anonymous >> memory (hey, partial mappings of hugetlb pages! ;) ). >> >> After all, COW is an optimization to speed up fork and defer copying. It >> relies on memory overcommit, but that doesn't really apply to hugetlb, so we >> fake it ... > > Good summary. > >> >> One easy ABI break I had in mind was to simply *not* allow COW-sharing of >> anon hugetlb folios; for example, simply don't copy the page into the child. >> Chances are there are not really a lot of child processes that would fail >> ... but likely we would break *something*. So there is no easy way out :( > > Right, not easy. The thing is this is one spot out of many of the > specialties, it also may or may not be worthwhile to have dedicated time > while nobody yet has a problem with it. It might be easier to start with > v2, even though that's also hard to nail everything properly - the > challenge can come from different angles. > > Thanks for the sharings, helpful. I'll go ahead with the Power fix on > hugepd putting this aside.
Yes, hopefully we already do have a test case for that. When writing gup_longterm.c I was more focusing on memfd vs. ordinary file systems ("filesystem type") than how it's mapped into the page tables.
> > I hope that before the end of this year, whatever I'll fix can go away, by > removing hugepd completely from Linux. For now that may or may not be as > smooth, so we'd better still fix it.
Crossing fingers, I'm annoyed whenever I stumble over it :)
-- Cheers,
David / dhildenb
| |