| Message ID | 20250415024532.26632-22-songmuchun@bytedance.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Eliminate Dying Memory Cgroup | expand |
On Mon, Apr 14, 2025 at 7:47 PM Muchun Song <songmuchun@bytedance.com> wrote: > > In the near future, a folio will no longer pin its corresponding > memory cgroup. So an lruvec returned by folio_lruvec() could be > released without the rcu read lock or a reference to its memory > cgroup. > > In the current patch, the rcu read lock is employed to safeguard > against the release of the lruvec in zswap_folio_swapin(). > > This serves as a preparatory measure for the reparenting of the > LRU pages. > > Signed-off-by: Muchun Song <songmuchun@bytedance.com> No objections from my end. AFAICT, wrapping this in rcu should not break things, and we're in the slow path (disk swapping) anyway, so should not be a problem. Anyway: Acked-by: Nhat Pham <nphamcs@gmail.com>
On 2025/4/15 10:45, Muchun Song wrote: > In the near future, a folio will no longer pin its corresponding > memory cgroup. So an lruvec returned by folio_lruvec() could be > released without the rcu read lock or a reference to its memory > cgroup. > > In the current patch, the rcu read lock is employed to safeguard > against the release of the lruvec in zswap_folio_swapin(). > > This serves as a preparatory measure for the reparenting of the > LRU pages. > > Signed-off-by: Muchun Song <songmuchun@bytedance.com> It should be rare to race with folio reparenting process, so it seems ok not to "reparent" this counter "nr_disk_swapins". Reviewed-by: Chengming Zhou <chengming.zhou@linux.dev> Thanks. > --- > mm/zswap.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/mm/zswap.c b/mm/zswap.c > index 204fb59da33c..4a41c2371f3d 100644 > --- a/mm/zswap.c > +++ b/mm/zswap.c > @@ -752,8 +752,10 @@ void zswap_folio_swapin(struct folio *folio) > struct lruvec *lruvec; > > if (folio) { > + rcu_read_lock(); > lruvec = folio_lruvec(folio); > atomic_long_inc(&lruvec->zswap_lruvec_state.nr_disk_swapins); > + rcu_read_unlock(); > } > } >
diff --git a/mm/zswap.c b/mm/zswap.c index 204fb59da33c..4a41c2371f3d 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -752,8 +752,10 @@ void zswap_folio_swapin(struct folio *folio) struct lruvec *lruvec; if (folio) { + rcu_read_lock(); lruvec = folio_lruvec(folio); atomic_long_inc(&lruvec->zswap_lruvec_state.nr_disk_swapins); + rcu_read_unlock(); } }
In the near future, a folio will no longer pin its corresponding memory cgroup. So an lruvec returned by folio_lruvec() could be released without the rcu read lock or a reference to its memory cgroup. In the current patch, the rcu read lock is employed to safeguard against the release of the lruvec in zswap_folio_swapin(). This serves as a preparatory measure for the reparenting of the LRU pages. Signed-off-by: Muchun Song <songmuchun@bytedance.com> --- mm/zswap.c | 2 ++ 1 file changed, 2 insertions(+)