Rename get_mem_cgroup_from_entry() to mem_cgroup_from_entry() and use
the zswap_pools_lock for next_shrink update.
Suggested-by: Yosry Ahmed
Signed-off-by: Nhat Pham
---
mm/zswap.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/mm/zswap.c
On Mon, Nov 6, 2023 at 12:58 PM Yosry Ahmed wrote:
>
> > >
> > > This lock is only needed to synchronize updating pool->next_shrink,
> > > right? Can we just use atomic operations instead? (e.g. cmpxchg()).
> >
> > I'm not entirely sure. I think in the pool destroy path, we have to also
> > put
> >
> > This lock is only needed to synchronize updating pool->next_shrink,
> > right? Can we just use atomic operations instead? (e.g. cmpxchg()).
>
> I'm not entirely sure. I think in the pool destroy path, we have to also
> put the next_shrink memcg, so there's that.
We can use xchg() to
On Mon, Nov 6, 2023 at 12:26 PM Yosry Ahmed wrote:
>
> On Mon, Nov 6, 2023 at 10:32 AM Nhat Pham wrote:
> >
> > From: Domenico Cerasuolo
> >
> > Currently, we only have a single global LRU for zswap. This makes it
> > impossible to perform worload-specific shrinking - an memcg cannot
> >
On Mon, Nov 6, 2023 at 10:32 AM Nhat Pham wrote:
>
> From: Domenico Cerasuolo
>
> Currently, we only have a single global LRU for zswap. This makes it
> impossible to perform worload-specific shrinking - an memcg cannot
> determine which pages in the pool it owns, and often ends up writing
>
From: Domenico Cerasuolo
Currently, we only have a single global LRU for zswap. This makes it
impossible to perform worload-specific shrinking - an memcg cannot
determine which pages in the pool it owns, and often ends up writing
pages from other memcgs. This issue has been previously observed
