From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-23.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A84BC433DB for ; Thu, 14 Jan 2021 19:21:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E401123B1A for ; Thu, 14 Jan 2021 19:21:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E401123B1A Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5BC3F8D0111; Thu, 14 Jan 2021 14:21:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 56B208D00F0; Thu, 14 Jan 2021 14:21:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 433058D0111; Thu, 14 Jan 2021 14:21:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0160.hostedemail.com [216.40.44.160]) by kanga.kvack.org (Postfix) with ESMTP id 2D8D18D00F0 for ; Thu, 14 Jan 2021 14:21:33 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id EBF022484 for ; Thu, 14 Jan 2021 19:21:32 +0000 (UTC) X-FDA: 77705349624.13.slave83_2809df127529 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id CBD6818140B8A for ; Thu, 14 Jan 2021 19:21:32 +0000 (UTC) X-HE-Tag: slave83_2809df127529 X-Filterd-Recvd-Size: 6376 Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Thu, 14 Jan 2021 19:21:32 +0000 (UTC) Received: by mail-lf1-f52.google.com with SMTP id a12so9658232lfl.6 for ; Thu, 14 Jan 2021 11:21:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gLR7tJSqZDJ94D80hcCnSLHwLTptQ2J0gGagY6O6kkE=; b=ZabjK8EKGctAttyGJ8ACroVT7psR/kMOT5Aa30fRWAfZ8FSup21Cor5KFzzQWoEgv0 WsLElfyU+qwkPOwYKtcLnOyy+bDdMtvRhKzGrIehY4oKA23SBmxmzlFzLknrmewUnyn7 RUi9JEETjQjMEbT114bVhbvnmi0AAGWQdTjr14fr7tH80AuMA+MBLYfGFO8VvwsO4FOV 1nzIYuc/hsMzbhjcy9vzHS8XaYBBX+3QbzZLKeyH/No9Fp040X2OLLs922Z4Xiehe9ga eMjUf1TAs+XQ4xyEpotaK3ekwIkqIuaa/u6/QxRrbgNvCY7QFl/wuXAhmuhMDPnwdRZi Hysw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gLR7tJSqZDJ94D80hcCnSLHwLTptQ2J0gGagY6O6kkE=; b=aVdhWXJGuRBIcsFS1lIei2ti2GKbESS59FMs7GQLnsRzK54vCumhr6Rw4WoHiqpV7v 2Mf7sckaABI+w1xnAaV4U53DSntRVKdD2wnK1d7FVJT94uaCPibcgTDiIoi0WM9g/Tr3 1tWNlwelTn8yEZaqdIg8dWncgOyEvV4D6qMAB8lw1X3/FeSN7M7YvCsaeE0u9XpWQDzY npmqW1HS8qA/J6PtMEc/Sv6NpTZ76MjtoNXm0sA9WPTDEPPKJezQ0eyGFqjKGLS3/wH4 ROmd5bPLW+fGCRgzxC57vXX8Pmu/g++S48LZRZLAXSM68Not431YNNoj1gEKbnOIXwc8 ODJw== X-Gm-Message-State: AOAM533I0SDIM363uRtGvEPK2LPnNjDvnUQSB+p2FDYdPs93Fkl3642W i7lN0/XuD5Yx9bP0gCEMMG8HiVsjsKGUjYksa9qNrQ== X-Google-Smtp-Source: ABdhPJx8Q1BItnF/qoFSFrFKR2OJEtzKZEw0e80guo5kkDf5/nuB9vU+OquzD08OXJTQTo/WDXq8BU9frS/yq/1hYYo= X-Received: by 2002:a05:6512:39c9:: with SMTP id k9mr1657175lfu.432.1610652090304; Thu, 14 Jan 2021 11:21:30 -0800 (PST) MIME-Version: 1.0 References: <1608894171-54174-1-git-send-email-tiantao6@hisilicon.com> <1608894171-54174-2-git-send-email-tiantao6@hisilicon.com> In-Reply-To: From: Shakeel Butt Date: Thu, 14 Jan 2021 11:21:19 -0800 Message-ID: Subject: Re: [RFC mm/zswap 1/2] mm/zswap: add the flag can_sleep_mapped To: Vitaly Wool Cc: Minchan Kim , Tian Tao , Seth Jennings , Dan Streetman , Andrew Morton , Barry Song , Linux-MM , Sergey Senozhatsky Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jan 14, 2021 at 11:05 AM Vitaly Wool wrote: > > On Thu, Jan 14, 2021 at 7:56 PM Minchan Kim 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 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 > > > > > --- > > > > > 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. Shakeel