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=-13.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 956EFC433E6 for ; Thu, 14 Jan 2021 19:29:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3931723B5F for ; Thu, 14 Jan 2021 19:29:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3931723B5F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 509448D0112; Thu, 14 Jan 2021 14:29:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B9898D00F0; Thu, 14 Jan 2021 14:29:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A6148D0112; Thu, 14 Jan 2021 14:29:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0121.hostedemail.com [216.40.44.121]) by kanga.kvack.org (Postfix) with ESMTP id 24A238D00F0 for ; Thu, 14 Jan 2021 14:29:06 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id DEE56181AEF3E for ; Thu, 14 Jan 2021 19:29:05 +0000 (UTC) X-FDA: 77705368650.13.wish99_610ef2527529 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id C6EB51814064E for ; Thu, 14 Jan 2021 19:29:05 +0000 (UTC) X-HE-Tag: wish99_610ef2527529 X-Filterd-Recvd-Size: 7075 Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Thu, 14 Jan 2021 19:29:05 +0000 (UTC) Received: by mail-oi1-f178.google.com with SMTP id d189so7067174oig.11 for ; Thu, 14 Jan 2021 11:29:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=lqPBcJmfKVzxuEePErDjwkrE3TseLiDdbm2PLTqPCUM=; b=u2w504sddEddgnMnGnlWvkgeQ11XlFEHeA3OHqeZ54wLn5uTwsu6fyYQoI5PYCLW9L P33I+RNM7H6Xcx5Knxgg805LuNdy1hPzhOu4cN7hl3Hgw+Ix5q9XdagPM6fv1HgDlMl7 0voh2zD299247gMPIIitICadbhUI8j0Hu7NaB6Y1iCKr4uTnNswfqxnJ/NM5QLMMjwd2 HPiEdmYQ1/If2XIiicbLt4qS74qTDtMdtNCjVGuEAmG3q3v9WJ7PlwOz/3njdplEyfy/ rAh96NAdH/VIvymDsaqYlCsoKLS4ZyymuHxJyLdx4fFOZblOnrp9UCOGsu02u6WadOLm ctbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=lqPBcJmfKVzxuEePErDjwkrE3TseLiDdbm2PLTqPCUM=; b=IGqxt4VNjMx7HEaqoiGb3uOoOee1xZc39z2kmLbTIEaclk9Y8ToFlF0p5ACWq5yXUt PYGKiLSrCCqUR49kV9zVi2NNYeTy+rM0byZYeK6EBYPALyD5/wMWq+g2Fs8VV5Yxkzca Xp9qOJXaaCC91ATpcirJVmVoV9akjnRnA5K2h4fSdVb0bGy0xNAYYogrmd6ecPgtxBJ5 eep4WMrg8yepbK9fOpnA1WDVujUIAqs1xyBOSF7mEbwgyjEwXgfTWOD/NUvJ24EZMiF5 eU05+0AadcHpE1rSHcAsgbFsqc7/0onkB8bBgGqUYZmcfTed6GD62EmIGIxLtbbgIwMG /Ydw== X-Gm-Message-State: AOAM533BPFkQdb1cjUxJPyAOpUBGi2t6ZtHiTkx6sdGVD8O2SOCPgi9y n08iT1M05qyQ4A8roMZmyww1sFPOYW8= X-Google-Smtp-Source: ABdhPJzKxc6YSq9XvBTlcW6nQzTFMnGTiQPNuZlKnfQc87/XwoETbZ5zPljWatB3DUdmoroChoItkg== X-Received: by 2002:a17:90b:f08:: with SMTP id br8mr6409221pjb.134.1610652237619; Thu, 14 Jan 2021 11:23:57 -0800 (PST) Received: from google.com ([2620:15c:211:201:7220:84ff:fe09:5e58]) by smtp.gmail.com with ESMTPSA id y6sm5916671pfn.145.2021.01.14.11.23.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Jan 2021 11:23:56 -0800 (PST) Date: Thu, 14 Jan 2021 11:23:54 -0800 From: Minchan Kim To: Shakeel Butt Cc: Vitaly Wool , Tian Tao , Seth Jennings , Dan Streetman , Andrew Morton , Barry Song , Linux-MM , Sergey Senozhatsky Subject: Re: [RFC mm/zswap 1/2] mm/zswap: add the flag can_sleep_mapped Message-ID: References: <1608894171-54174-1-git-send-email-tiantao6@hisilicon.com> <1608894171-54174-2-git-send-email-tiantao6@hisilicon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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:21:19AM -0800, Shakeel Butt wrote: > 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. Furthermore, please don't make mess for zpool semantic.