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 A53D7D4334F for ; Thu, 7 Nov 2024 11:49:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 00F116B009A; Thu, 7 Nov 2024 06:49:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F00136B009B; Thu, 7 Nov 2024 06:49:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA1046B009D; Thu, 7 Nov 2024 06:49:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id BBCAC6B009A for ; Thu, 7 Nov 2024 06:49:28 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 56F7D140651 for ; Thu, 7 Nov 2024 11:49:28 +0000 (UTC) X-FDA: 82759128480.29.FA5BC15 Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by imf13.hostedemail.com (Postfix) with ESMTP id A98CE2001C for ; Thu, 7 Nov 2024 11:48:49 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=eeFVDYtB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730979996; 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=EFFsDH3Mu5TMadcSw1srkjRsUpQh30Wi0O92w8u4+6U=; b=ghKsPsyLYpDNqFHr3dM32NwvkLkpInl4X7625PNEwbVonvfkprZMREhV72mVBax3X/Xj9F +ksAadfPRdRcGXl6UB3R5AHWUCN8kP7IibrCW3YuKsAvUEtH1T4Mv50wtqFqxnVsLanQr7 Y0VNVmdaziYFKKJYP2NH6gR2tCOf/jM= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=eeFVDYtB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730979996; a=rsa-sha256; cv=none; b=dKy8AikviiZ2WTIcbrczGu+im4E/uS3EQascUGejY5WbMfEvcHOmnj5+U79gG4IkDvPuZh TZtwH0LxjpnWlN+FSIbVZgnUS4YjCbmN0IVzmKNkn/ZfWctKVf2pwIZv5CWQhzM++JFLKA AB2p8DGzqkhvpyjyIqUArVd3G86i87w= Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-539f72c8fc1so1325709e87.1 for ; Thu, 07 Nov 2024 03:49:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730980164; x=1731584964; 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=EFFsDH3Mu5TMadcSw1srkjRsUpQh30Wi0O92w8u4+6U=; b=eeFVDYtB4cLiWsSaQ4wXS/ZauUDP6WbmNHgzEtlCprvhNFEttTC7miykIssdAHNZ6u R12wp7tCQaR+CYQrLhvlLL/OStxtWBnAGr96d4f88Tg/KQYUyeNcG9oD3YYIYL7nU6fj ijlFEVUFbcsTmO62OCXBqZUzgDdIYL0NBNbc6+g80riYOVc3xSemBFgCrqZgscYhT1hS Gl2zDKr7wfVAGoypiTzE8oUWBypwD8GQghaTrirc64jBLy1FXSirT4PUd88XE8yGbDes HIkFKxRXcqLxIcWdsRZLhHHyIqsUwe2IjpXwDYtK+ZyFjvKBHWgRldhmn+zG1iGaOvtA 8FAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730980164; x=1731584964; 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=EFFsDH3Mu5TMadcSw1srkjRsUpQh30Wi0O92w8u4+6U=; b=mnq2vF/sxnEejPTrr3QfHHcVDfJpFnweBVHQiO6jDmmWdUZQJTfRFZZ96+Ai8rkUn1 gicbkBhnh2aIeUmArk1IRbA9cjjSFTt4Yu/locDDlugGLUvWMFGr5b0Hiq6HmEwugyAi JANsnTdE7Ejl81jYEJHzOdp2mudgD5irVz31gyV9ViWpIpzNVRB8nCRb0bX4siMLaEjY CSksttP2fcHx9iEw71Di4yijQlxfPRYknBkMF/ltMuHhlutk6B7t6zbJN+sJNS9ANrVL xqWeCK39bV67gRjM2hIdRdmA+1+2F/1W5OZ7ea7NHYZtVmVvD5fX6f+rxDmG3uG2rD6Q N2CA== X-Forwarded-Encrypted: i=1; AJvYcCVg+/aePD5BeHYlfYB1KCIHyzMQwz8r2k9O1ZruYMNnqQ9t0qCyE5ljJhPVZtMJbG9p8JjvZP3nrA==@kvack.org X-Gm-Message-State: AOJu0Yx647GD7csdFIhCo0ukxiXQglb1yFyW/jabXjwnOkyhzjBSdMt+ 0OYKzJUY1sfZdcIkLGnBkLQSh4VD+ui1JYAfJICATe3d8YU8vBYv X-Google-Smtp-Source: AGHT+IEjGs0GpGaOS2ecdEB9mYTJBJRH2L9b6YQ3R7UJnbJCAX+MOCsP9YvF6DS0ys/O3skA8V/wgw== X-Received: by 2002:a05:6512:110d:b0:539:f13c:e5d1 with SMTP id 2adb3069b0e04-53d840a29femr525991e87.38.1730980163970; Thu, 07 Nov 2024 03:49:23 -0800 (PST) Received: from ?IPV6:2a02:6b67:d751:7400:c2b:f323:d172:e42a? ([2a02:6b67:d751:7400:c2b:f323:d172:e42a]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-432aa6b2c32sm57167285e9.10.2024.11.07.03.49.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Nov 2024 03:49:23 -0800 (PST) Message-ID: <490a923e-d450-4476-a9f5-2a247b6d3a12@gmail.com> Date: Thu, 7 Nov 2024 11:49:22 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC 2/2] zram: support compression at the granularity of multi-pages To: Barry Song <21cnbao@gmail.com> Cc: akpm@linux-foundation.org, axboe@kernel.dk, chrisl@kernel.org, corbet@lwn.net, david@redhat.com, kanchana.p.sridhar@intel.com, kasong@tencent.com, linux-block@vger.kernel.org, linux-mm@kvack.org, minchan@kernel.org, nphamcs@gmail.com, senozhatsky@chromium.org, surenb@google.com, terrelln@fb.com, v-songbaohua@oppo.com, wajdi.k.feghali@intel.com, willy@infradead.org, ying.huang@intel.com, yosryahmed@google.com, yuzhao@google.com, zhengtangquan@oppo.com, zhouchengming@bytedance.com, bala.seshasayee@linux.intel.com, Johannes Weiner References: <20240327214816.31191-3-21cnbao@gmail.com> <20241021232852.4061-1-21cnbao@gmail.com> Content-Language: en-US From: Usama Arif In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: A98CE2001C X-Stat-Signature: edp4d1eut5syadmzkekhnaaszjmhxqrr X-Rspam-User: X-HE-Tag: 1730980129-18220 X-HE-Meta: U2FsdGVkX1961yJv1nSNnrdK7stCm/tZg5umFka4TiKMPRymknhKuHKd7b6um17XJCD41LVFrvfRVlpyXhAUAh9EMBXFQHvQ64eciAtPtHWssQi2MtLtraARyj5sv9k80vFoDNrzpodN25dx/RmOumnXIuYrn3745nzolCPw4rhM0QSaStjxBscRE8ZEmZcBjUAFtT9FZ/+T8jwAD/tiauK2M7mLuJUR7FF86IKB+C6wD+wln+GdQFhSNSiZgZwSyWtmfoMPks0BLBwiwvysfJftfQJzA3WFhUEIx9hUNpWoG0psVauXC67GlJfdgmuYvYGJmBy9bUsMnHJMvemfXrK1Eh75GCFgY6Vdl2k7XXcGe1SHihia5TmWNPg7Sj7Toiv/FhmAhnMo3Gj5oXUQ8+pLF5GEGXQHl9JTcnO4gR6gws0sze9kYVbzvaB9zY1OPp4/hTQUq9f1Qr6ugB4MVslWVE1/P9ZAy7GhMrxxofuAHfwI4KmxMxdQhjqcgdARg/wxuFzkr1hi30hC8sLP0FeoQjCtIGUIC2vP3VYzI/zAUou06kY3Hjhvx+AUmZsP56HzUQZXj6mu7qQWZT8em+Z7N0NmPh2b5W0YtiOqGbk0jkcXBlcVMoULAtOxBam7L7L8DP6mFMKOeFQKMIpoYyvliwi9i9EaTDTtBQYuGMwKndOi4kZg/eLHAqyT10bXovtbZzuOVLCL46AcNOk1jT73eW1ABpsG9Dh3d06Fra2hmsK5BIIC7TYnWwrBO+w8fBVVakASuL6t8jeD54mCexUgxh5jVGEwvR3P2O6FAuIwZBmB+fZbfIBzr2NGc9pO7x793b964DTqTCciHCy7zYQJzBLPrwOewr0S9zgUY5Gkmq2hBxdrfbdAnIpMlEkP5KQ9C++eg8okJNrY7mUli9s5BgbwiGSHNkUzr2LkD7A/ZbBVop8rcAOKzt+o3LhgXm6Vokg5FMpwUKRn/7G KnSKvgoq D9gleWdObEMUcURHYeDXZtVl8+ecPnl64/tGOPj+O6Pgd4YVE7rBh2AVXRd90UzvIt+ZVQ8YkW9LmecXeyB0WHutDTNSWCKlsKb39mfecUR7CWdK5So1tKKcOqWkYSO/3yE5G33D7s8VPK9mmJCeG1bROemssa6vJCtT9toOOSFEC0ZlcuEjJGCJ3AZAOi2gyqEBK4pcVFoqHqArYndEiMDzBdjJRdxr+ECFLGPgpyqTSG0EBkvVwlNEMiAc3Gu3gfIDu9eMigP6YPX///Bj5eTt5meKN/y7swsa+OcljbbvKH/NE0xLyhS/9snral34pgfM9lqR6zuoc+XevVVpEtq0LEXaJFRwcMSTNEdPpgZwAEeN99vkmCoWDKUpGmg7ZuIYuqUCvxdJrq+njE76CALGZn9Aiy+2VZXALm9xJ8x5fsE7+EhwXhMGxc/UyZvle/528oQlO+k1VyUv/NuTbMfCNner7KIMmls9slMrSEIw9T+JN/CZtfQGOqmFeEMX0yeWw X-Bogosity: Ham, tests=bogofilter, spamicity=0.000070, 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 07/11/2024 10:31, Barry Song wrote: > On Thu, Nov 7, 2024 at 11:25 PM Barry Song <21cnbao@gmail.com> wrote: >> >> On Thu, Nov 7, 2024 at 5:23 AM Usama Arif wrote: >>> >>> >>> >>> On 22/10/2024 00:28, Barry Song wrote: >>>>> From: Tangquan Zheng >>>>> >>>>> +static int zram_bvec_write_multi_pages(struct zram *zram, struct bio_vec *bvec, >>>>> + u32 index, int offset, struct bio *bio) >>>>> +{ >>>>> + if (is_multi_pages_partial_io(bvec)) >>>>> + return zram_bvec_write_multi_pages_partial(zram, bvec, index, offset, bio); >>>>> + return zram_write_page(zram, bvec->bv_page, index); >>>>> +} >>>>> + >>> >>> Hi Barry, >>> >>> I started reviewing this series just to get a better idea if we can do something >>> similar for zswap. I haven't looked at zram code before so this might be a basic >>> question: >>> How would you end up in zram_bvec_write_multi_pages_partial if using zram for swap? >> >> Hi Usama, >> >> There’s a corner case where, for instance, a 32KiB mTHP is swapped >> out. Then, if userspace >> performs a MADV_DONTNEED on the 0~16KiB portion of this original mTHP, >> it now consists >> of 8 swap entries(mTHP has been released and unmapped). With >> swap0-swap3 released >> due to DONTNEED, they become available for reallocation, and other >> folios may be swapped >> out to those entries. Then it is a combination of the new smaller >> folios with the original 32KiB >> mTHP. > Hi Barry, Thanks for this. So in this example of 32K folio, when swap slots 0-3 are released zram_slot_free_notify will only clear the ZRAM_COMP_MULTI_PAGES flag on the 0-3 index and return (without calling zram_free_page on them). I am assuming that if another folio is now swapped out to those entries, zram allows to overwrite those pages, eventhough they haven't been freed? Also, even if its allowed, I still dont think you will end up in zram_bvec_write_multi_pages_partial when you try to write a 16K or smaller folio to swap0-3. As want_multi_pages_comp will evaluate to false as 16K is less than 32K, you will just end up in zram_bio_write_page? Thanks, Usama > Sorry, I forgot to mention that the assumption is ZSMALLOC_MULTI_PAGES_ORDER=3, > so data is compressed in 32KiB blocks. > > With Chris' and Kairui's new swap optimization, this should be minor, > as each cluster has > its own order. However, I recall that order-0 can still steal swap > slots from other orders' > clusters when swap space is limited by scanning all slots? Please > correct me if I'm > wrong, Kairui and Chris. > >> >>> >>> We only swapout whole folios. If ZCOMP_MULTI_PAGES_SIZE=64K, any folio smaller >>> than 64K will end up in zram_bio_write_page. Folios greater than or equal to 64K >>> would be dispatched by zram_bio_write_multi_pages to zram_bvec_write_multi_pages >>> in 64K chunks. So for e.g. 128K folio would end up calling zram_bvec_write_multi_pages >>> twice. >> >> In v2, I changed the default order to 2, allowing all anonymous mTHP >> to benefit from this >> feature. >> >>> >>> Or is this for the case when you are using zram not for swap? In that case, I probably >>> dont need to consider zram_bvec_write_multi_pages_partial write case for zswap. >>> >>> Thanks, >>> Usama >> > > Thanks > barry