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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A56ACC3DA6E for ; Mon, 25 Dec 2023 14:33:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B94876B006E; Mon, 25 Dec 2023 09:33:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B44FD6B0071; Mon, 25 Dec 2023 09:33:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A0C716B0072; Mon, 25 Dec 2023 09:33:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 928F56B006E for ; Mon, 25 Dec 2023 09:33:03 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6454E120481 for ; Mon, 25 Dec 2023 14:33:03 +0000 (UTC) X-FDA: 81605582646.04.06BEA29 Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) by imf22.hostedemail.com (Postfix) with ESMTP id CD4EFC0004 for ; Mon, 25 Dec 2023 14:32:59 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=do2b2Gpu; spf=pass (imf22.hostedemail.com: domain of zhouchengming@bytedance.com designates 209.85.210.173 as permitted sender) smtp.mailfrom=zhouchengming@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703514781; a=rsa-sha256; cv=none; b=5R3uGZ6Q/zzsW0eYFhELEtomn799xp8GkjXaAPWpelokntrC6QkVJfFjqC2ODswoMFkykQ 4AHu21G75Rbq4hIDIy/c/v4VT0uYPdStuZqmf2V92A5JbG1BE76nq5AksGl0gCRAPbUIWI cMDMso7iUcqaL/akCIyKV6JKitiD/q8= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=do2b2Gpu; spf=pass (imf22.hostedemail.com: domain of zhouchengming@bytedance.com designates 209.85.210.173 as permitted sender) smtp.mailfrom=zhouchengming@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703514781; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=SLJwaknLZDjEeoCIcHASwS2cRi032Xc+xd0onyr4mDI=; b=eLaLZ5BZPZOi9arpD99JBLshtF7dJQd772L5+Aw1yT0vzol7KudcdQ1hwmpB8eAtY16qww bBkEy++UReVR1gDqzRHJoVxg07WF3vl3lxlXA6YP7ukOtN/2MyAfGI/dkd1h/kjFQTVbj4 5BOihVvDkAXqVYzstn4WbSViQ0P0CE4= Received: by mail-pf1-f173.google.com with SMTP id d2e1a72fcca58-6d9bba6d773so457923b3a.1 for ; Mon, 25 Dec 2023 06:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1703514778; x=1704119578; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=SLJwaknLZDjEeoCIcHASwS2cRi032Xc+xd0onyr4mDI=; b=do2b2Gpu6dMPoV7g1TQi1f+Gy7ES7WcKpFbjzUKeNQ6MXQ+vcZ2qHBC1STieBc0azc cnGt7ur1ABpIVPBxrPvgR9YysdghwKQbLSYuUbLqVt/dpl7c5gkIIrlrseOApEJ0hwZF gJXxBfWWpVQn8Iil3QJD0F1xKi71nmPFvXDm0l4tciT2MdWocmPB3gDm5pD7c61lvJBL vR8rfOhWVazcvB8404L13qaOOkIBAtKzLNgAjpuDHd06/pz6oh6f0sFitvw22uA6lr84 FWwE9z8JDvUMrHEAdSonUvrzGj/32ViaPJseMqDcYBA1FmPc7lnOP6Dav2StK+Jhmgo1 E9hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703514778; x=1704119578; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SLJwaknLZDjEeoCIcHASwS2cRi032Xc+xd0onyr4mDI=; b=jjoVDSEMIwa85lydYb/ey6vK46Huev1GBTfSSJiOS4n/CDSCOSTHOy0+efZGzNJ5ov 6g9FsvcuybnFPX/AyYSCFmPGF8RzmfuhYLbbgEhU3SNJbq+ZmG4O9aDbP0sqBtoiBUws A5HHWGnF1eVuxsrLVvYlpYCYEEtB2bsLLocFTX2bc7m/PAurF5Z8TNGpQpSkveba6pMM pMDDrTHV9BUU5sv4w4AtyKSPVSYISXWPu/BeQHIVwdbF5CqQAlBRityvqAt+JOX2kpjM 2LA5IoXqqC6k9t2QrM9xZ/6pYH6k4vge8UvO9rJ3g6WXvV2YUX6+xucwWMQWA9hV6hIR 9e0Q== X-Gm-Message-State: AOJu0Yx1AEkzPTTacoO8vTEGtTxPLSaka/xNLdsimObnM4gOwXxJZu/u oXx6FoSWK66SppZCLYJ/sTvgmWEh/O24RA== X-Google-Smtp-Source: AGHT+IFHA9tZu4HDYWQPfdl1A3ES590rB3P8abnapC73FPUp70BWgaVDGE5VDZrbPBcxMpUgtCLJHA== X-Received: by 2002:a05:6a20:ba82:b0:194:c6d3:1bda with SMTP id fb2-20020a056a20ba8200b00194c6d31bdamr6166408pzb.120.1703514778309; Mon, 25 Dec 2023 06:32:58 -0800 (PST) Received: from [10.254.172.83] ([139.177.225.244]) by smtp.gmail.com with ESMTPSA id e17-20020a630f11000000b005c6007a13b5sm7807307pgl.25.2023.12.25.06.32.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Dec 2023 06:32:57 -0800 (PST) Message-ID: <7d4e59b7-ddaf-45b9-909c-9ecb8ff5a34d@bytedance.com> Date: Mon, 25 Dec 2023 22:32:44 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 6/6] mm/zswap: directly use percpu mutex and buffer in load/store To: Chris Li Cc: Yosry Ahmed , Nhat Pham , Seth Jennings , Vitaly Wool , Dan Streetman , Johannes Weiner , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20231213-zswap-dstmem-v3-0-4eac09b94ece@bytedance.com> <20231213-zswap-dstmem-v3-6-4eac09b94ece@bytedance.com> <2a22e9b5-dc8c-4c4d-81c2-2f4e1850cf3d@bytedance.com> Content-Language: en-US From: Chengming Zhou In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: CD4EFC0004 X-Stat-Signature: 3udnfzeu5n36txnz3x7oird4p1gfup89 X-Rspam-User: X-HE-Tag: 1703514779-332923 X-HE-Meta: U2FsdGVkX1/YaScWfjem4zHlWix4qdGh8v0FHz5zcfg+Qu9K0OvQcmp4/WkTr0KfG/6rzUtDgQdkTJbQPqCuldDbpwWKz1KjP/bGFwAiQkysIhykXivfVjfvQjnz8C9RtuW5/RFOxtPvZWb869lvUXt332FgC2KSpKA2624M1r2izmHZRTNFM+6Id51Nd1NRJV8f27jYOYmd7IP/p9gdysLP0U0qT50BDkuA8gRManzvD0oiojOxAX14mUclnOi8FrMVVUB0+udj1kJ95pHssKx+gJGNY8M1WtnEYTapy0UBtJKX9dAU16czw20AxOCAiHFFouuaxNccQ8no5raM0AQoH0XWUiKW15zcAE5Fu7yidJcDaATgCEEOsR1hhC7K/ZfkN+6un+h8ffO6ZMPjpMLjL8tq5BY+G62nzUJxOa637Abt7+2a+BXOM5xCcTymkgImr62Faq9YADLAZxbd5P7QaySJDMB5W28IxdJYcd7ydevvcGjHhVk4HUARZt5N9SC8KdH0GtNPV80pKRU0/iieLjiKi8AHNenc+k8ywQaaLRly7CWskQWDnl86mZF4TkjnGc3QrKlF/HJ/hqID+rw3KpG/g5inxly1v37BUMBbheJRwYX9j2sLtEk1dxQQI+ncxdpxu7n6XxPUGkiOtD9r7eCxiYlcEcdins0JQ/Wr6Hf9Y9cA6lS7ySmk8C6x/IkBcxYI5Gw0YbPvaNqv3eI0JaNeAXUhLDR/PjjEhbK46iZ4uA6R0qPjZnRVwyBT8WK+eZh3hZGKrBP3HDhDGzAqIhQPvQFUF/ozFlIog2E4YX8aDnHC54kLFtxdf89UvElER9uALeAngZo5KCkOMoak2ROkKNThV/0tXgyPts8mxvL0RQOqTM5lZkFhzk2bWPyD/XVAPw/eRC1dZGmO1k0cmwYxuhuJVvnPfJbfhfnRK8SK2iXOEtoEoESWQFEoVvL13WaHcf+BuHE0KnX bNWDcOI/ fNWeK7ghavJgazs0FkWqDRGrPHcfudvPCLVUbvAcprnuVx4DRZFPmVEgSZr1nhkItRCWIECajAoYTq6lH3eWgDEg2Yy7Ans/fubzwq6MMD0u7bw+PF86eTM/LVmsigG9qLDmPzxqLZ3DVMgFVdCdraKYkn2kNr25Npaz3MEqXbqUhddfi8pN1rwsLs4IPTg24WTsyBqRV4QfZbPQgCUctZ6W8tGjuCGAgItLaGVn+wSz+3BjKiV6RGtnU/mTpjDG5porkGC2xtQuRLDRACdXPoFD241ZfTQIUA00nTuE+ZZdyZ//UN+ZtRW6ZtDhb4mkrPLx60TpGnQLOjuvtX0Ef9sNG5RgR5HppbN1I/sWt8E0bExcty9GiEGEu7l6Hm0N9gtsGAfzLagUZXxu1HWqAjKQILr+VDrSfCajoFAaKd1n3TsZB1ENUCUPC1y7vd/acu+M7FEglWpIcXPxAndCPzm/bSA== 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: List-Subscribe: List-Unsubscribe: On 2023/12/23 01:37, Chris Li wrote: > Hi Chengming, > > The patch looks good to me. > > Acked-by: Chris Li (Google) > Thanks. [...] >> >> I think there are two viewpoints here, both works ok to me. >> >> The first is from ownship or lifetime, these percpu mutex and dstmem >> are shared between all pools, so no one pool own the mutex and dstmem, >> nor does the percpu acomp_ctx in each pool. >> >> The second is from usage, these percpu mutex and dstmem are used by >> the percpu acomp_ctx in each pool, so it's easy to use to put pointers >> to them in the percpu acomp_ctx. >> >> Actually I think it's simpler to let the percpu acomp_ctx has its own >> mutex and dstmem, which in fact are the necessary parts when it use >> the acomp interfaces. > > Agree, that is why I prefer to keep the struct together. I am fine > with what Yosry suggested and the anonymous struct, just consider it > is not critically necessary. > Agree, I have no strong opinion about it, so will just leave it as it is. >> >> This way, we could delete the percpu mutex and dstmem, and its hotplugs, > > That is the real value of this patch. Thanks for doing that. > >> and not shared anymore between all pools. Maybe we would have many pools >> at the same time in the future, like different compression algorithm or >> different zpool for different memcg workloads. Who knows? :-) > > As long as the zswap is not re-enterable, e.g. never have the nested > page fault that causes zswap_load within another zswap_load, I think > we are fine having more than one pool share the buffer. In fact, if we > trigger the nested zswap load, I expect the kernel will dead lock on > the nested mutex acquire because the mutex is already taken. We will > know about kernel panic rather than selient memory corruption. > >> >> So how about this patch below? Just RFC. >> >> Subject: [PATCH] mm/zswap: make each acomp_ctx has its own mutex and dstmem > > Thank you for doing that, you can consider submitting it as the real > patch instead of the RFC. I see real value in this patch removing some > per CPU fields. Ok, will update. Thanks!