Messages in this thread | | | Subject | Re: [PATCH 5/5] mm/thp: Split huge pmds/puds if they're pinned when fork() | From | John Hubbard <> | Date | Wed, 23 Sep 2020 13:19:08 -0700 |
| |
On 9/23/20 8:44 AM, Peter Xu wrote: > On Wed, Sep 23, 2020 at 04:01:14PM +0200, Jan Kara wrote: >> On Wed 23-09-20 09:50:04, Peter Xu wrote: ... >>>> But the problem is that if you apply mm->has_pinned check on file pages, >>>> you can get false negatives now. And that's not acceptable... >>> >>> Do you mean the case where proc A pinned page P from a file, then proc B >>> mapped the same page P on the file, then fork() on proc B? >> >> Yes.
aha, thanks for spelling out the false negative problem.
>> >>> If proc B didn't explicitly pinned page P in B's address space too, >>> shouldn't we return "false" for page_likely_dma_pinned(P)? Because if >>> proc B didn't pin the page in its own address space, I'd think it's ok to >>> get the page replaced at any time as long as the content keeps the same. >>> Or couldn't we? >> >> So it depends on the reason why you call page_likely_dma_pinned(). For your >> COW purposes the check is correct but e.g. for "can filesystem safely >> writeback this page" the page_likely_dma_pinned() would be wrong. So I'm >> not objecting to the mechanism as such. I'm mainly objecting to the generic >> function name which suggests something else than what it really checks and >> thus it could be used in wrong places in the future... That's why I'd >> prefer to restrict the function to PageAnon pages where there's no risk of >> confusion what the check actually does. > > How about I introduce the helper as John suggested, but rename it to > > page_maybe_dma_pinned_by_mm() > > ? > > Then we also don't need to judge on which is more likely to happen (between > "maybe" and "likely", since that will confuse me if I only read these words..). >
You're right, it is too subtle of a distinction after all. I agree that sticking with "_maybe_" avoids that confusion.
> I didn't use any extra suffix like "cow" because I think it might be useful for > things besides cow. Fundamentally the new helper will be mm-based, so "by_mm" > seems to suite better to me. > > Does that sound ok? >
Actually, Jan nailed it. I just wasn't understanding his scenario, but now that I do, and considering your other point about wording, I think we end up with:
anon_page_maybe_pinned()
as a pretty good name for a helper function. (We don't want "_mm" because that refers more to the mechanism used internally, rather than the behavior of the function. "anon_" adds more meaning.)
...now I better go and try to grok what Jason is recommending for the new meaning of FOLL_PIN, in another tributary of this thread. I don't *think* it affects this naming point, though. :)
thanks, -- John Hubbard NVIDIA
| |