Re: [RFC mm/zswap 1/2] mm/zswap: add the flag can_sleep_mapped

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 14, 2021 at 11:21:19AM -0800, Shakeel Butt wrote:
> On Thu, Jan 14, 2021 at 11:05 AM Vitaly Wool <vitaly.wool@xxxxxxxxxxxx> wrote:
> >
> > On Thu, Jan 14, 2021 at 7:56 PM Minchan Kim <minchan@xxxxxxxxxx> wrote:
> > >
> > > On Thu, Jan 14, 2021 at 07:40:50PM +0100, Vitaly Wool wrote:
> > > > On Thu, Jan 14, 2021 at 7:29 PM Minchan Kim <minchan@xxxxxxxxxx> wrote:
> > > > >
> > > > > On Fri, Dec 25, 2020 at 07:02:50PM +0800, Tian Tao wrote:
> > > > > > add a flag to zpool, named is "can_sleep_mapped", and have it set true
> > > > > > for zbud/z3fold, set false for zsmalloc. Then zswap could go the current
> > > > > > path if the flag is true; and if it's false, copy data from src to a
> > > > > > temporary buffer, then unmap the handle, take the mutex, process the
> > > > > > buffer instead of src to avoid sleeping function called from atomic
> > > > > > context.
> > > > > >
> > > > > > Signed-off-by: Tian Tao <tiantao6@xxxxxxxxxxxxx>
> > > > > > ---
> > > > > >  include/linux/zpool.h |  3 +++
> > > > > >  mm/zpool.c            | 13 +++++++++++++
> > > > > >  mm/zswap.c            | 50 +++++++++++++++++++++++++++++++++++++++++++++-----
> > > > > >  3 files changed, 61 insertions(+), 5 deletions(-)
> > > > > >
> > > > > > diff --git a/include/linux/zpool.h b/include/linux/zpool.h
> > > > > > index 51bf430..e899701 100644
> > > > > > --- a/include/linux/zpool.h
> > > > > > +++ b/include/linux/zpool.h
> > > > > > @@ -73,6 +73,7 @@ u64 zpool_get_total_size(struct zpool *pool);
> > > > > >   * @malloc:  allocate mem from a pool.
> > > > > >   * @free:    free mem from a pool.
> > > > > >   * @shrink:  shrink the pool.
> > > > > > + * @sleep_mapped: whether zpool driver can sleep during map.
> > > > >
> > > > > I don't think it's a good idea. It just breaks zpool abstraction
> > > > > in that it exposes internal implementation to user to avoid issue
> > > > > zswap recently introduced. It also conflicts zpool_map_handle's
> > > > > semantic.
> > > > >
> > > > > Rather than introducing another break in zpool due to the new
> > > > > zswap feature recenlty introduced, zswap could introduce
> > > > > CONFIG_ZSWAP_HW_COMPRESSOR. Once it's configured, zsmalloc could
> > > > > be disabled. And with disabling CONFIG_ZSWAP_HW_COMPRESSOR, zswap
> > > > > doesn't need to make any bounce buffer copy so that no existing
> > > > > zsmalloc user will see performance regression.
> > > >
> > > > I believe it won't help that much -- the new compressor API presumes
> > > > that the caller may sleep during compression and that will be an
> > > > accident waiting to happen as long as we use it and keep the handle
> > > > mapped in zsmalloc case.
> > > >
> > > > Or maybe I interpreted you wrong and you are suggesting re-introducing
> > > > calls to the old API under this #ifdef, is that the case?
> > >
> > > Yub. zswap could abstract that part under #ifdef to keep old behavior.
> >
> > We can reconsider this option when zsmalloc implements reclaim
> > callback. So far it's obviously too much a mess for a reason so weak.
> >
> 
> Sorry I don't understand the link between zsmalloc implementing shrink
> callback and this patch. This patch is adding an overhead for all
> zswap+zsmalloc users irrespective of availability of hardware. If we
> want to add support for new hardware, please add without impacting the
> current users.

Furthermore, please don't make mess for zpool semantic.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux