On Thu, Jan 13, 2022 at 12:57:35PM +0100, Michal Hocko wrote: > 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? Yes. > So you can move the lock down to the > callback which examines respective pages. Or is there anything > preventing that? No. > 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. Agreed. > Code paths which need a stable memcg are supposed to be using > folio_memcg_lock for the specific examination time. No argument here, just a clarification: when possible I prefer to lock a batch of pages rather than individual ones. > If you prefer a > trylock approach for this usecase then we can add one. Done. Thanks.
