Re: [PATCH v3] mm/migrate: don't batch the TLB flush when there is nothing to batch

["Huang, Ying" <ying.huang@linux.alibaba.com>]

Zhiteng Qiu <qiuzhiteng@hygon.cn> writes:

> On 11/9/26 14:07, David Hildenbrand (Arm) wrote:

[snip]

>> I am not quite happy about the folio_mapcount() check, though: as soon as we
>> optimize try_to_unmap() to batch better for large folios, it would be just plain
>> wrong.
>
> That makes sense. A large folio's mapcount alone would not tell us
> how many separate flushes are needed once its PTEs can be handled
> in a batch.
>
> Would it make sense to restrict the optimization to a single,
> singly mapped small folio and keep batching for all large folios,
> as in the scope of v2? The changelog performance numbers were
> measured with the v2 check. Or do you have a different direction
> in mind?

If there's any behavior change, please rerun the test to verify.  It's
fine to reuse the result data if they are similar enough.

>
> Moving the check to the caller would read the mapcount before
> locking the folio. My understanding is that a concurrent change
> could only affect which flush path is chosen, and both paths are
> correct. Please let me know if I'm missing a concurrency concern.
>
> Ying, since you suggested using folio_mapcount(), would you be
> comfortable with limiting the optimization to small folios?

I'm OK with it.  Thanks to David for pointing out that folio_mapcount()
isn't good here because we will optimize large folio tlb flushes.

[snip]

---
Best Regards,
Huang, Ying