Re: [RFC PATCH 0/9] introduce PGTY_mgt_entry page_type

[David Hildenbrand]

> > If you cannot prove that the optimization has some practical effect,
> > it's hard to persuade others for increased complexity.
>
> To be honest, this patch stems from an issue I noticed during code review.
>
> When this patchset was completed, I did put in some effort to find its
> benefits, and it was only
>
> under such an exaggeratedly constructed test scenario that the effect
> could be demonstrated. :(

I mean, thanks for looking into that and trying to find a way to improve 
it. :)


That VMA walk is the real problem, stopping earlier is just an 
optimization that works in some cases. I guess on average it will 
improve things, although probably really hard to quantify in reality.

I think tracking the #migration entries might be a very good debugging tool.

A cleaner and more reliably solution regarding what you tried to 
implement would be able to

(a) track it in a separate counter, at the time we establish/remove a 
migration entry, not once the mapcount is already 0. With "struct folio" 
getting allocated separately in the future this could maybe be feasible 
(and putting it under a config knob).

(b) doing it also for large folios as well


(b) might be tricky with migration entries being used for THP splits, 
but probable it could be special-cased somehow, I am sure.


--
Cheers,

David / dhildenb