"David Hildenbrand (Arm)" <[email protected]> writes:
> On 8/3/26 17:03, Sean Christopherson wrote:
>> On Fri, Jul 31, 2026, David Hildenbrand (Arm) wrote:
>>> I sent a fix for the GUP code that always makes us drain right now:
>>>
>>> https://lore.kernel.org/r/20260731-check_and_migrate_movable_folios-v1-1-e0002d7b7...@kernel.org
>>>
>>> Would the following (agains mm-unstable + fix) work for you?
>>>
>>>
>>> I assume that you'd have to call it as
>>>
>>> lru_cache_drain_for_folio(folio, 0, NULL);
>>>
>>> But maybe there are indeed extra references that are not reflected in
>>> folio_expected_ref_count() that you would have to consider? I doubt it, but
>>> please check if
>>> there would be a problem.
>>>
>>> There is a small problem for merging:
>>>
>>> (1) The patch depends on the fix.
>>>
>>> (2) mm/swap.c was moved to mm/folio.c in the mm tree.
>>>
>>> We could write what I have below against Linus' tree and have the conflict
>>> be
>>> resolved when merging. Topic branches are unfortunately not yet a thing in
>>> MM
>>> land.
>>
>> Are you expecting the aforementioned fix to land in 7.2, 7.3, or 7.4? If
>> it's
>
> Andrew wants to give it some more time in -next, so I'm expecting it to land
> for 7.3.
>
>> 7.2 or 7.3, then I would strongly prefer to base v10 on linux-next (where
>> the fix
>> will presumably land soonish), and target 7.4 for in-place conversion. Then
>> v10> can be applied against an early 7.3-rcN and we don't need to juggle
>> branches
>> (assuming Andrew is ok taking the proposed patch through the KVM tree).
>
> Agreed. We'd also have to get the actual preparation patch into 7.3. I can
> send it out
> and coordinate with Andrew.
>
Thank you!
When we were discussing this earlier at guest_memfd biweekly, before
deciding to refactor out a function like lru_cache_drain_for_folio(), we
did say that the likelihood of actually draining in practice is low,
especially on a machine with heavy load making allocations all the time.
I think the threads with Xiaoyao have resolved, I can put v10 out
tomorrow. Would it be okay to go with the following from v8, and then
clean up later when lru_cache_drain_for_folio() is available?
I added in David's suggestions to check for dma pinning and mapping
before draining to trim cases where draining happens in the version
below:
static bool kvm_gmem_is_safe_for_conversion(struct inode *inode, pgoff_t start,
size_t nr_pages, pgoff_t *err_index)
{
struct address_space *mapping = inode->i_mapping;
const int filemap_get_folios_refcount = 1;
pgoff_t last = start + nr_pages - 1;
struct folio_batch fbatch;
bool lru_drained = false;
bool safe = true;
pgoff_t next;
int i;
folio_batch_init(&fbatch);
next = start;
while (safe && filemap_get_folios(mapping, &next, last, &fbatch)) {
for (i = 0; i < folio_batch_count(&fbatch);) {
struct folio *folio = fbatch.folios[i];
safe = (folio_ref_count(folio) ==
folio_nr_pages(folio) +
filemap_get_folios_refcount);
if (safe) {
++i;
} else if (!lru_drained &&
folio_may_be_lru_cached(folio) &&
!folio_maybe_dma_pinned(folio) &&
!folio_mapped(folio)) {
lru_add_drain_all();
lru_drained = true;
} else {
*err_index = max(start, folio->index);
break;
}
}
folio_batch_release(&fbatch);
cond_resched();
}
return safe;
}
I'm hoping not to push this back by a full cycle to 7.4, and also hold
back other series dependent on this one.
> --
> Cheers,
>
> David
