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 2D7A9D41D44 for ; Tue, 12 Nov 2024 01:25:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B4DE76B0085; Mon, 11 Nov 2024 20:25:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AD6446B00CE; Mon, 11 Nov 2024 20:25:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 94DF16B00D0; Mon, 11 Nov 2024 20:25:22 -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 75B156B0085 for ; Mon, 11 Nov 2024 20:25:22 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 28DC61402A8 for ; Tue, 12 Nov 2024 01:25:22 +0000 (UTC) X-FDA: 82775699286.04.9B23660 Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) by imf22.hostedemail.com (Postfix) with ESMTP id 4D3FEC0007 for ; Tue, 12 Nov 2024 01:24:29 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=D69hSV5j; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731374633; 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=5Jb8HZFwjTgBBgQWpyumYyekfI9KcaXCVTYppwT7xjU=; b=t94jVLEOkYod5s/KqqQqgHYvLlllY2kcILezF+k5950wy2vvUfqrK29Wnr7xeY04OiOgX+ 9Ipcs7AlfeamFhApwh1Yz+kD9/YTxFfOOzEOpDCWSEsOEaJrSWOBsMjLa99siD8ZLOP8Op by3htnV2mEIdgGAjloDfJDls2kepfqc= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=D69hSV5j; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731374633; a=rsa-sha256; cv=none; b=PkT57l1bKYjTjvVPhT9Jp9ZGqXNRVGCOmG6V1YBvHYMg9b67zTLH/FfqVKaOcsTsqw40Jx 5yQd6U9lHk5ew9jhMnSekqkk3VwulTNRJxbfCBi9O3077TVf3mjKWwlc7toEp44l/5IiEt Yi/1Wsg5YJDHdK8Uhs4qvfgPzbkUK8A= Received: by mail-vk1-f178.google.com with SMTP id 71dfb90a1353d-513de426719so2096111e0c.0 for ; Mon, 11 Nov 2024 17:25:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731374719; x=1731979519; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5Jb8HZFwjTgBBgQWpyumYyekfI9KcaXCVTYppwT7xjU=; b=D69hSV5jm+lnBWD4aThgwceI7TkaSzb7GHXmaOByOk0tThnv2m8iMf5C0wH9KFa74U 0ljm+cYv3jbKKpm2cqjfDBJ8bnyHHMVdRmX0OyjQwde8OXLKz6vypu71ZdGM3uSHdMN7 RPFk14clt2kqvnVH7zWf2EGCvipYpvDQuO7B1czhO9UL1rDi4CwJBcG8a5L1eqjFCNyy XulaDv3654GwNmllQ3KMPS9PTWrQr2ZNumwBBycq+3RmkdF4mQbqFBIRt1gjwXl4k/qM VDxaj83bBHDEAjQBjlXceZmA0onsFf24F1u1c8TzLDfG2RsMNOKtQC8sMIbgd0FzugJV eQRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731374719; x=1731979519; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5Jb8HZFwjTgBBgQWpyumYyekfI9KcaXCVTYppwT7xjU=; b=cFC/KtOGfyQ5wOlylZa03FuztNUVkzLAXfpI1FuB7SXp9LrJpIbISrbiZVu46uT/WJ 7/jVRhi0Yo5/laxuypdnwSitTshPJ6zEYvSwDNSYXMqTkhj1etiuPbLjYYw7+kufQT/u cBUU+9WuJG6AQ/l9I1DgA/PDqmswyAhhqEE2HPsB9SZGiWTGUef8+piu47uc4CEc6GLn Gyc3/r7lLjNvd2/lbBbZhdkG2EvX8t2sd6nawVlJf6dvgiKq+V7NfNxhSzUbvJCw+D65 NcIs+sb8FEqYVlGVWUdId1lg4IMtbUTpe+DGZN8Ay7hTxmGSuoGvJGBfu8pOGo4ggzTh qFpw== X-Gm-Message-State: AOJu0Yz8BLy6oJ/ygYP1Cb/2o+xXGJP1tmQLGnFCmkCKjIgUaMVmbSXh dlm8d172fKHjHErC3F1yYvuOdEEHAfoGPEOJlOePDsmcMNrh0htV4IL6tAJnQ3ybWVJO1ft5WlD Xy8USFeQlbwMwWJ/H4fsZSUG0Ql0= X-Google-Smtp-Source: AGHT+IESKdmJLz3BQ/czXr6ySr7v/cZowB2uRuxM5sPu1mAN9fnOFfYjMoB216FVIDyikFzvneMbFhNHq9JyffnnPtI= X-Received: by 2002:a05:6102:3f4e:b0:4a4:7928:637c with SMTP id ada2fe7eead31-4ac297a4616mr975258137.8.1731374719449; Mon, 11 Nov 2024 17:25:19 -0800 (PST) MIME-Version: 1.0 References: <20241107101005.69121-1-21cnbao@gmail.com> <87iksy5mkh.fsf@yhuang6-desk2.ccr.corp.intel.com> <87pln1z2da.fsf@yhuang6-desk2.ccr.corp.intel.com> In-Reply-To: <87pln1z2da.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Barry Song <21cnbao@gmail.com> Date: Tue, 12 Nov 2024 14:25:08 +1300 Message-ID: Subject: Re: [PATCH RFC v2 0/2] mTHP-friendly compression in zsmalloc and zram based on multi-pages To: "Huang, Ying" Cc: linux-mm@kvack.org, akpm@linux-foundation.org, axboe@kernel.dk, bala.seshasayee@linux.intel.com, chrisl@kernel.org, david@redhat.com, hannes@cmpxchg.org, kanchana.p.sridhar@intel.com, kasong@tencent.com, linux-block@vger.kernel.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, yosryahmed@google.com, yuzhao@google.com, zhengtangquan@oppo.com, zhouchengming@bytedance.com, usamaarif642@gmail.com, ryan.roberts@arm.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 4D3FEC0007 X-Stat-Signature: 3sapyoygpb6g57eist7kzq6qerjgiy1o X-HE-Tag: 1731374669-820266 X-HE-Meta: U2FsdGVkX1+Ai9NpmnIy3ZXloMnLXF6/WOx/1bbK+/dakyRy0qgXCAni6cilRe+2uxXzR43mBgP0VNRVTzcgr/CL3/IP7EW9cLXvBc7H2P4Dvy2jTb6gl1fuR6wxUNjKnM/vnY4YKMB75hd0qDb52QqSZmWHFGv+LQlx+UD/6IrOzfaBE7lyJcr0Q+a3jb0fYvtMCCfPsam4NErd8PzGYhCMinhTgI5y8cxQqTDLuENzv01k7O9eYJmU4YA4WwrKG+2WNiHzHqfCUeC22uPqhsIqRcuuYTzoNyJRifj5pJCVU//tsxgqU5WdnJYTZuJ64SXP1waa5PeBOYL3tPZ3WNeawagRPlano4w4lMQ5wHHccnpA/j1csNfCEYv63n2GGOR7cFxZxua/g+RgFLnGNlIeAJDobk3J65x2dZg6zBe4G7+l+eGzDP3DGkeqpyFCQXjf5BlNvl5To53sYBLkf6BtDeYu/utgsQrCObpkrB/ZPYEMgI/4Sm+xXeGj2T3jTnc7pYMq+dxWFb6d73ItkpWe3snEpY7Xvimb+H4dj4htzOHjedJQrLTCFeMse072JDuVGE2EXVHwyOXYN2ove9t50z6HpYe6kUN97SYOn5AuGfXRULmtreHXVz2mITMh8VNwR8gwxTmtinGqA97mbglnQaEzC2nLR0TfRBapgq941nLDW8qZL04jsjPXt8hHp2IoAwn3TMq5/i3GdLqdW7LfqL+O5QspHJqZXbRGhEEN//Uu7iQ2pclHi5rfvs98YpJ8XIqKN0wJhmPTnnjjMROO1i0LEc//aTp3AuETLSBBxWG+yuJT1GZ0bBWe8Ro34EUBsDB0D0rRdh8IeEJkMqBZsn/2mHFwPoTpvOiIcPhVMH+bNtNXiWYZWUppk9b+wXNwWd4PyV8KUm2SaUFcKhjBK3hgFvXB5R3/WSEWjzTRX2C3yek/u4t8E5UPOsbrypGNhs48O5BYL4/85EM oC6teG3V 7FvL4IGxoqS2wB/kNfJ4sFJ5Kg6Tq4z6Qnjwt35NDXGW+7maU8WokEod+Gk7D2TDngT9DGzOrzUb/XLPvHScDofEGtzJnDRqO9lexSDovAIsXxbzas5PKmBSJjJKPxHjeIBIQijB3d5Q+9FRNoLKmi9nzqAA7QtNQtoqzXdPL1AO+vemMQSEjkwABF1h04inOALsZoyuPLd0M2JfpBVVLDb/aai8DnwWOtXPvMw+4f7h+EIfX0riVdH9CYF5622GBE5eGW8ocsCInZ/9hKZ4JQd+Rejk58ElFGctFA99gKkOZ6l+cMMJ2Iym8Z/BGapDtsr6JQc3p0eKx0GAQ6OPPSswkSJDn584ynIJet4uICq2RgroFHWbiMDjyTvj5mb6Ou9Dm 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 Tue, Nov 12, 2024 at 2:11=E2=80=AFPM Huang, Ying = wrote: > > Barry Song <21cnbao@gmail.com> writes: > > > On Fri, Nov 8, 2024 at 6:23=E2=80=AFPM Huang, Ying wrote: > >> > >> Hi, Barry, > >> > >> Barry Song <21cnbao@gmail.com> writes: > >> > >> > From: Barry Song > >> > > >> > When large folios are compressed at a larger granularity, we observe > >> > a notable reduction in CPU usage and a significant improvement in > >> > compression ratios. > >> > > >> > mTHP's ability to be swapped out without splitting and swapped back = in > >> > as a whole allows compression and decompression at larger granularit= ies. > >> > > >> > This patchset enhances zsmalloc and zram by adding support for divid= ing > >> > large folios into multi-page blocks, typically configured with a > >> > 2-order granularity. Without this patchset, a large folio is always > >> > divided into `nr_pages` 4KiB blocks. > >> > > >> > The granularity can be set using the `ZSMALLOC_MULTI_PAGES_ORDER` > >> > setting, where the default of 2 allows all anonymous THP to benefit. > >> > > >> > Examples include: > >> > * A 16KiB large folio will be compressed and stored as a single 16Ki= B > >> > block. > >> > * A 64KiB large folio will be compressed and stored as four 16KiB > >> > blocks. > >> > > >> > For example, swapping out and swapping in 100MiB of typical anonymou= s > >> > data 100 times (with 16KB mTHP enabled) using zstd yields the follow= ing > >> > results: > >> > > >> > w/o patches w/ patches > >> > swap-out time(ms) 68711 49908 > >> > swap-in time(ms) 30687 20685 > >> > compression ratio 20.49% 16.9% > >> > >> The data looks good. Thanks! > >> > >> Have you considered the situation that the large folio fails to be > >> allocated during swap-in? It's possible because the memory may be ver= y > >> fragmented. > > > > That's correct, good question. On phones, we use a large folio pool to = maintain > > a relatively high allocation success rate. When mTHP allocation fails, = we have > > a workaround to allocate nr_pages of small folios and map them together= to > > avoid partial reads. This ensures that the benefits of larger block co= mpression > > and decompression are consistently maintained. That was the code runni= ng > > on production phones. > > > > We also previously experimented with maintaining multiple buffers for > > decompressed > > large blocks in zRAM, allowing upcoming do_swap_page() calls to use the= m when > > falling back to small folios. In this setup, the buffers achieved a > > high hit rate, though > > I don=E2=80=99t recall the exact number. > > > > I'm concerned that this fault-around-like fallback to nr_pages small > > folios may not > > gain traction upstream. Do you have any suggestions for improvement? > > It appears that we still haven't a solution to guarantee 100% mTHP > allocation success rate. If so, we need a fallback solution for that. > > Another possible solution is, > > 1) If failed to allocate mTHP with nr_pages, allocate nr_pages normal (4k= ) > folios instead > > 2) Revise the decompression interface to accept a set of folios (instead > of one folio) as target. Then, we can decompress to the normal > folios allocated in 1). > > 3) in do_swap_page(), we can either map all folios or just the fault > folios. We can put non-fault folios into swap cache if necessary. > > Does this work? this is exactly what we did in production phones: [1] https://github.com/OnePlusOSS/android_kernel_oneplus_sm8650/blob/oneplu= s/sm8650_u_14.0.0_oneplus12/mm/memory.c#L4656 [2] https://github.com/OnePlusOSS/android_kernel_oneplus_sm8650/blob/oneplu= s/sm8650_u_14.0.0_oneplus12/mm/memory.c#L5439 I feel that we don't need to fall back to nr_pages (though that's what we used on phones); using a dedicated 4 should be sufficient, as if zsmalloc is handling compression and decompression of 16KB. However, we are not adding them to the swapcache; instead, they are mapped immediately. > > >> > >> > -v2: > >> > While it is not mature yet, I know some people are waiting for > >> > an update :-) > >> > * Fixed some stability issues. > >> > * rebase againest the latest mm-unstable. > >> > * Set default order to 2 which benefits all anon mTHP. > >> > * multipages ZsPageMovable is not supported yet. > >> > > >> > Tangquan Zheng (2): > >> > mm: zsmalloc: support objects compressed based on multiple pages > >> > zram: support compression at the granularity of multi-pages > >> > > >> > drivers/block/zram/Kconfig | 9 + > >> > drivers/block/zram/zcomp.c | 17 +- > >> > drivers/block/zram/zcomp.h | 12 +- > >> > drivers/block/zram/zram_drv.c | 450 +++++++++++++++++++++++++++++++= --- > >> > drivers/block/zram/zram_drv.h | 45 ++++ > >> > include/linux/zsmalloc.h | 10 +- > >> > mm/Kconfig | 18 ++ > >> > mm/zsmalloc.c | 232 +++++++++++++----- > >> > 8 files changed, 699 insertions(+), 94 deletions(-) > >> > > -- > Best Regards, > Huang, Ying Thanks barry