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 3FD2ED3ABF3 for ; Mon, 11 Nov 2024 19:30:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B52186B0098; Mon, 11 Nov 2024 14:30:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B018E6B0099; Mon, 11 Nov 2024 14:30:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9F0386B009A; Mon, 11 Nov 2024 14:30:25 -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 819B96B0098 for ; Mon, 11 Nov 2024 14:30:25 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id AE360161AC4 for ; Mon, 11 Nov 2024 19:30:24 +0000 (UTC) X-FDA: 82774803720.08.6050C0D Received: from mail-qv1-f48.google.com (mail-qv1-f48.google.com [209.85.219.48]) by imf26.hostedemail.com (Postfix) with ESMTP id EEE9614002F for ; Mon, 11 Nov 2024 19:29:51 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kycug0qz; spf=pass (imf26.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.48 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731353335; 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=TIPHrV/grHNzykAgYDbMyU7FEE0Nh6yMI4U0iBFfsPE=; b=mwOYb7bJXdWk4ZjjJ+epyOg1dxTM+VDF7stg5DYdluSDA+wyAuyTHsYRi7gPmSLqr9gWcV zqb49O9KWhkJJ7e8rZJl4+BUCWJ/EGXfBZ+2RUs+ANs2+HHcoFz83WTHboMJKUgtuxPct4 sTnyXD1LB8WUtV5AlzyMNDekMkGHkSA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731353335; a=rsa-sha256; cv=none; b=aucUm/Kc7FY5TX1vKlJmCgh1V817YDlcKtnc87ueLKEk7qqLnc5n3RRAnb2XP4lNYvY5Wc VMoQtDplC5ZqqPp+/70h6k5F5Kw1UtcXXRrQVoKgYBqvq7+bXIM8pBuE7bnlY9pPQ7LxSt yEkp8xfwHWnEv/UIAi9bpvRVifZbpMU= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kycug0qz; spf=pass (imf26.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.48 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qv1-f48.google.com with SMTP id 6a1803df08f44-6d396a6f6aaso36849156d6.2 for ; Mon, 11 Nov 2024 11:30:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731353422; x=1731958222; 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=TIPHrV/grHNzykAgYDbMyU7FEE0Nh6yMI4U0iBFfsPE=; b=kycug0qz/W2da/VMul9ZgRVwNCPNrck5dHgPs0y4vYDr4p6Usdl0Tztw+EvtIrVZEt PGij2o9L//viT7EUKrurcG6SPOZbB67TflKKs9hBrUJGw8NjCp/aWAp14uo4YhinFkGp kjwLyCGso9Cwuyf6aDPBCwsne1ZrynROLDnwHzbcNpv/TlLUaX2INZZnjx6jho/SjOg3 0PljtD4dZRHwx7MWBl5+0g+2AcH78N1e3T/pLj99+E4eX1Ax6M7gGTQYUSECaKD7j8Df xcZQOOa0rgr0psUbB505DporuQVsKNc9rRf24OAtDK46yHVTuiI3i0clbdG1DlLYqKKL //Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731353422; x=1731958222; 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=TIPHrV/grHNzykAgYDbMyU7FEE0Nh6yMI4U0iBFfsPE=; b=Ve++L/QoFr/oMgbspDeGXlqKEKLa48UWF0OWpb7EHmYSUNz47Mt+ZDiB89H7MTV4VZ KaKSf6VnFqB+jvthJGzyInVO541QglvKX7lBHbvRo/wM0scDU/Fic3y9yw5xyZ1ljC9v so0ZjSnMoQRhBT+K2szss6chbvcMYx6BLqpf1D7qghF164z0STB5+KnoXGvx6lPeeEPX UQjkW2oF2cH32zMji+63lCGUxCFXMCb7D5BJsyCLeLT+SqhgXbemK1X7EGG2LUxViH+/ 9lV8CIw+kfPMZZYJhHtVajeJXUaD77U8tbYB8usiq9m9Ho+xMUCFXCQJCkkBcsZ/LnFH 9eGQ== X-Gm-Message-State: AOJu0YwRudA2WfGlK/oMxxieWeSZ+6Cz08DT3KXcrmwyfapPGgCsDXRV aLaszuBs7+IA9/kcGLDcmghLCaCYUo5G6Y7QVN/upnnMmEiRR+aOrgJSBw1YApRLMKTrbtPN4zD uB1s/92Iaf2OHV9wYmB9S67LhfgI= X-Google-Smtp-Source: AGHT+IF6H9uKWdhSy8hQxrLtR0220qSD5a3V16tGcZsPlk9aBUmDO2c6eRw/heN4g6WrIQ9pWxnJFDgg+cq2/NYL8dA= X-Received: by 2002:a05:6214:3202:b0:6d3:6542:8496 with SMTP id 6a1803df08f44-6d39e107d0fmr213458966d6.10.1731353421996; Mon, 11 Nov 2024 11:30:21 -0800 (PST) MIME-Version: 1.0 References: <20241107101005.69121-1-21cnbao@gmail.com> In-Reply-To: <20241107101005.69121-1-21cnbao@gmail.com> From: Nhat Pham Date: Mon, 11 Nov 2024 11:30:10 -0800 Message-ID: Subject: Re: [PATCH RFC v2 0/2] mTHP-friendly compression in zsmalloc and zram based on multi-pages To: Barry Song <21cnbao@gmail.com> 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, 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, usamaarif642@gmail.com, ryan.roberts@arm.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam10 X-Stat-Signature: 3sjmkp1hhz8a1wzzr1kc4ujuxtf1ozrw X-Rspamd-Queue-Id: EEE9614002F X-Rspam-User: X-HE-Tag: 1731353391-320819 X-HE-Meta: U2FsdGVkX1/J/X9beYUDGIz+tUHvN52KHUVO4isZeAHoz63/KYoC8flc1HW7md7Z6agWU7QgxQGCxse6IbjVGqPApkxHptez8LbCij6k7mK/JYndivQJDaY6AfE3i3XTzHdDl/GmgTp4Zn+RYqIAovoecdrdk/kM6tHua7Gm6HFShyAjlZEFZ6SCsMvSN0P6q+W5cWJ1FH7fnh1QxR+X1VKqvnB+384w0m5GCfyNRDrE4AYTDAC185nJZci46mKj76ba7tiWwPqvjABdP99ulhCzGr6yxJC+as42TH/dicmnx0iYgz1hCXqJBxhG6OaRI6eh0zVYYA0lyG8y5Xz0vEJsAO+/xiCOlKEsxtuXXjkEGx9Gz4SuFhWLWGJWw1cTiBkwy1S4OBeTY+EYjSz7yh/8nbEJ5ikn1bL3BVw1HjNEw13R2Qfs2ogaOp3bff8F6s5iWxrHsNRNW0+BiLqg8B895VRvuJDNLz96z6NlRb19Ni3tvNK1OHe0L/rcbtu0xzDVu8HjJGX0KS9il/c5wq1bALOJyDDmWTHjwapoQj2qOj/JXuW6tlUyYwPhshzE1ZCKyiuMUx6r3B7UrROSo0vkXLfErMS/70n+NeBScgaRdKwxQ72f+633YAAGvZZvhXcKjo80J5XpLch6TgERJjCBoEAxmXBohC6GERmGSGnyO2yajsTEKoptDUonuySXyODSPdilfczSN5aoohQYcGaHuIBjTw8vKXLHwyqxOvnKM4xx0VlIzjCQG+WCj6Rz9o1NzzA5+VT3NCN+m1nmBEYqV6ee8wwRANpAmcRth/Btr41pNysfenhIxvHs+jlUn4eco/nPRaqeGGFXM5QdT+A2frelatSn0nrMfkio/LnrRH99bC1q2oJwGn8NxCboy3Qyt7FTk9zmlD/ioj5PNR3oOy0tdsov8jarDwzu32SqUjEm1QQVjb6s0A6BroVUm/aOJsu+r32KAWb600J xpGXfEtG DV1bhy9+Qmsv3lw4IY9RrxHvap4yay06Gxl+C0SdY4eiNtBZHA+HuPxz+pr6GIzzY5W2GBumeF0bnCBR3yDSmHN9QmEY89ih3PYIQVbfmnqrdWeMBp8QyaRU1qK3RHkuwPjH3Fyf+J3gjn+pgUKbR9KOFr0qIyYRqbi2/FMPd2A+/eCM+hAMxjQ3sk0osJ+Lh1Gxf1qCo0z5rbCtTsyMrE/lp6k0feyaa8+bJFgq6WKe8MNiBGn7AKglp6c0CjdA4t+enRFX2N/ab6+d+E5IZTewbMrS5KfhkbElBe1tpx8R4mvBOGPcVE918v/xWtUJW7ZkpA7EX+GMxBawJuA2/YkGbcv/FBum3zPcGjvXtLnNAiJ5ow0cRKaZcGA== 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 Thu, Nov 7, 2024 at 2:10=E2=80=AFAM Barry Song <21cnbao@gmail.com> wrote= : > > 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 granularities. > > This patchset enhances zsmalloc and zram by adding support for dividing > 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 16KiB > block. > * A 64KiB large folio will be compressed and stored as four 16KiB > blocks. > > For example, swapping out and swapping in 100MiB of typical anonymous > data 100 times (with 16KB mTHP enabled) using zstd yields the following > 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 very promising :) My understanding is it also results in memory saving as well right? Since zstd operates better on bigger inputs. Is there any end-to-end benchmarking? My intuition is that this patch series overall will improve the situations, assuming we don't fallback to individual zero order page swapin too often, but it'd be nice if there is some data backing this intuition (especially with the upstream setup, i.e without any private patches). If the fallback scenario happens frequently, the patch series can make a page fault more expensive (since we have to decompress the entire chunk, and discard everything but the single page being loaded in), so it might make a difference. Not super qualified to comment on zram changes otherwise - just a casual observer to see if we can adopt this for zswap. zswap has the added complexity of not supporting THP zswap in (until Usama's patch series lands), and the presence of mixed backing states (due to zswap writeback), increasing the likelihood of fallback :)