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.
