On Wed 12-01-22 16:43:15, Yu Zhao wrote: > On Wed, Jan 12, 2022 at 11:17:53AM +0100, Michal Hocko wrote: [...] > > Is there any reason you are not using folio_memcg_lock in the > > pte walk instead? > > We have a particular lruvec (the first arg), hence a particular memcg > to lock. But we don't have a particular page to lock. That is certainly true at this layer but the locking should be needed only for specific pages, no? So you can move the lock down to the callback which examines respective pages. Or is there anything preventing that? To be honest, and that is the reason I am asking, I really do not like to open code the migration synchronization outside of the memcg proper. Code paths which need a stable memcg are supposed to be using folio_memcg_lock for the specific examination time. If you prefer a trylock approach for this usecase then we can add one. -- Michal Hocko SUSE Labs
