On Thu, Jun 25, 2026, David Hildenbrand (Arm) wrote: > On 6/25/26 02:35, Sean Christopherson wrote: > > One thought I had, to avoid the IPIs that draining all per-CPU caches > > requires, > > was to disallow putting guest_memfd pages in folio batches, e.g. by hacking > > something into folio_may_be_lru_cached(). But due to taking a per-lru lock, > > that would penalize the relatively hot path and definitely common operation > > of > > faulting in guest memory. On the other hand, memory conversion is already a > > relatively slow operation and is relatively uncommon compared to page > > faults, > > (and likely very uncommon for real world setups). I.e. having to drain all > > caches if conversion isn't safe penalizes a relatively slow, relatively > > uncommon > > path. > > Yeah, the lru_add_drain_all is rather messy. > > We have similar code in > > collect_longterm_unpinnable_folios(), where we first try a lru_add_drain(), to > then escalate to a lru_add_drain_all(). > > Maybe we could factor that (suboptimal code) out to not have to reinvent the > same thing multiple times?
As discussed in the guest_memfd call, we should do this straightaway, i.e. instead of merging this series as-is, so that we don't export lru_add_drain_all() only to drop the export a kernel or two later, and can instead export the helper to drain any batches for a folio (or set of folios/pages).
