Messages in this thread | | | Date | Sun, 23 Jan 2022 14:40:36 -0700 | From | Yu Zhao <> | Subject | Re: [PATCH v6 6/9] mm: multigenerational lru: aging |
| |
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.
| |