On 08.09.25 21:21, Anthony Yznaga wrote:
On 9/8/25 11:50 AM, David Hildenbrand wrote:
On 20.08.25 03:04, Anthony Yznaga wrote:
When handling a fault in an mshare range, redirect charges for page
tables and other allocations to the mshare owner rather than the
current task.
That looks rather weird. I would have thought there would be an easy way
to query the mshare owner for a given mshare mapping, and if the current
MM corresponds to that owner you know that you are running in the owner
context.
Of course, we could have a helper like is_mshare_owner(mapping, current)
or sth like that.
I'm not quite following you. Charges for newly faulted pages will be
automatically directed to the mshare owner because the mshare mm will
have its mm_owner field pointing to the owner. On the other hand,
allocations for page table pages are handled differently.
GFP_PGTABLE_USER causes the accounting to go through
__memcg_kmem_charge_page() which will charge them to the memcg for the
current task unless unless current->active_memcg is set to point to
another memcg.
As a note, I think at some point we discussed re-routing page faults to
the owner, so the owner can take care of all of that naturally. Is that
what's happening here?
So, are we running into that code that we have current be another MM
than vma->vm_mm?
Reminds me of: FOLL_REMOTE->FAULT_FLAG_REMOTE. But I guess, we don't
take care of different accounting in that case.
Anyhow, what I meant is that you could just check whether you have a
mshare VMA, and if so check if current is different to the mshare MM
owner. So I don't immediately see why MMF_MSHARE is required.
--
Cheers
David / dhildenb
