RE: [PATCH v7 4/8] mm: zswap: Refactor code to delete stored offsets in case of errors.

["Sridhar, Kanchana P" <kanchana.p.sridhar@intel.com>]

> -----Original Message-----
> From: Yosry Ahmed <yosryahmed@google.com>
> Sent: Tuesday, September 24, 2024 5:43 PM
> To: Sridhar, Kanchana P <kanchana.p.sridhar@intel.com>
> Cc: linux-kernel@vger.kernel.org; linux-mm@kvack.org;
> hannes@cmpxchg.org; nphamcs@gmail.com; chengming.zhou@linux.dev;
> usamaarif642@gmail.com; shakeel.butt@linux.dev; ryan.roberts@arm.com;
> Huang, Ying <ying.huang@intel.com>; 21cnbao@gmail.com; akpm@linux-
> foundation.org; Zou, Nanhai <nanhai.zou@intel.com>; Feghali, Wajdi K
> <wajdi.k.feghali@intel.com>; Gopal, Vinodh <vinodh.gopal@intel.com>
> Subject: Re: [PATCH v7 4/8] mm: zswap: Refactor code to delete stored
> offsets in case of errors.
> 
> On Tue, Sep 24, 2024 at 3:33 PM Sridhar, Kanchana P
> <kanchana.p.sridhar@intel.com> wrote:
> >
> > > -----Original Message-----
> > > From: Yosry Ahmed <yosryahmed@google.com>
> > > Sent: Tuesday, September 24, 2024 12:20 PM
> > > To: Sridhar, Kanchana P <kanchana.p.sridhar@intel.com>
> > > Cc: linux-kernel@vger.kernel.org; linux-mm@kvack.org;
> > > hannes@cmpxchg.org; nphamcs@gmail.com;
> chengming.zhou@linux.dev;
> > > usamaarif642@gmail.com; shakeel.butt@linux.dev;
> ryan.roberts@arm.com;
> > > Huang, Ying <ying.huang@intel.com>; 21cnbao@gmail.com; akpm@linux-
> > > foundation.org; Zou, Nanhai <nanhai.zou@intel.com>; Feghali, Wajdi K
> > > <wajdi.k.feghali@intel.com>; Gopal, Vinodh <vinodh.gopal@intel.com>
> > > Subject: Re: [PATCH v7 4/8] mm: zswap: Refactor code to delete stored
> > > offsets in case of errors.
> > >
> > > On Mon, Sep 23, 2024 at 6:17 PM Kanchana P Sridhar
> > > <kanchana.p.sridhar@intel.com> wrote:
> > > >
> > > > Added a new procedure zswap_delete_stored_offsets() that can be
> > > > called to delete stored offsets in a folio in case zswap_store()
> > > > fails or zswap is disabled.
> > >
> > > I don't see the value in this helper. It will get called in one place
> > > AFAICT, and it is a bit inconsistent that we have to explicitly loop
> > > in zswap_store() to store pages, but the loop to delete pages upon
> > > failure is hidden in the helper.
> > >
> > > I am not against adding a trivial zswap_tree_delete() helper (or
> > > similar) that calls xa_erase() and  zswap_entry_free() to match
> > > zswap_tree_store() if you prefer that.
> >
> > This is a good point. I had refactored this routine in the context
> > of my code that does batching and the same loop over the mTHP's
> > subpages would get called in multiple error condition cases.
> >
> > I am thinking it might probably make sense for say zswap_tree_delete()
> > to take a "folio" and "tree" and encapsulate deleting all stored offsets
> > for that folio. Since we have already done the computes for finding the
> > "tree", having that as an input parameter is mainly for latency, but if
> > it is cleaner to have "zswap_tree_delete(struct folio *folio)", that should
> > be Ok too. Please let me know your suggestion on this.
> >
> 
> What I meant is "zswap_tree_delete(struct xarray *tree, pgoff_t
> offset)", and loop and call this  in zswap_store(). This would be
> consistent on looping and calling zswap_store_page().
> 
> But we can keep the helper as-is actually and just rename it to
> zswap_tree_delete() and move the loop inside. No strong preference.

Ok, sounds good.

Thanks,
Kanchana