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 61278C282DE for ; Mon, 10 Mar 2025 17:31:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 11E7F28000B; Mon, 10 Mar 2025 13:31:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0CF73280004; Mon, 10 Mar 2025 13:31:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E6BF728000B; Mon, 10 Mar 2025 13:31:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C3938280004 for ; Mon, 10 Mar 2025 13:31:03 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 1D8631CB87B for ; Mon, 10 Mar 2025 17:31:05 +0000 (UTC) X-FDA: 83206332090.29.E1084BC Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by imf10.hostedemail.com (Postfix) with ESMTP id F2F48C0017 for ; Mon, 10 Mar 2025 17:31:02 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hwSoxLw3; spf=pass (imf10.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.160.172 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=1741627863; 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=b78KlAfyXKoBfZcmMN7ECuBnSEo3W7UZ1w2TCHUTUXU=; b=aDFDWSD+wKrSkxEvroOJFemrukBBPFxikNYm/eOEzx5dPs3x37Z4iVzAZQceGP+22ceY7z cQtANpOxshzmXZG9eevAoBpSYoFxmSnpk8vMku8CdQs8iiL9lp21qHHHtETqROU2SVIDd+ UKUTxtvOqIbzssxM0WQkz14eI1XBlWI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741627863; a=rsa-sha256; cv=none; b=XqJefBSoRDSdDU508Re1Av6U8wEs0yk5552uIHuSjVWTZDCNpKPGBBsbeblFLqrx/Im6IP 2SZapstx42K2D1SSiBaZKL3FfqXlLH/Bv3JdSQBOS5bu+Nc6raHULdkqpxkHiO94iMYK1u EQrP36/lA3qCZKAgAsxSQOB0v1T5zcc= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hwSoxLw3; spf=pass (imf10.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.160.172 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-47690a4ec97so9086421cf.2 for ; Mon, 10 Mar 2025 10:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741627861; x=1742232661; 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=b78KlAfyXKoBfZcmMN7ECuBnSEo3W7UZ1w2TCHUTUXU=; b=hwSoxLw3ZWqQF+ycSVad/B1sEcnzYxSC64I8+VpdF0yYqEa0k4Bo6IvvVFYKQFmdjZ 4dtoEmp9rvb0TB4CtxJpGkJdsveyvymA6tvipJ9hS+OVo6HZWT/JPJyu9jMvb0gJg9Qa Ilkq/Vp1sCx3wBRYhvCELibE+PxseTLIBmdFTOZqCTiXZBeLQSSo0bpoD8xpWyz9e/Ss SrwDbW3uWThrpzHo7I+ta3MCPGNQ/Rv5+tbq4sSEDco2BKujthHeFcJC36Wfu+b4PAum pVPhrUlkQPEWfmuj6I6xtrCbJIqFCQxDGGeXHdRLDWQGdjopNUo1NUtq3BSZNTTT/g2r 8kvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741627861; x=1742232661; 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=b78KlAfyXKoBfZcmMN7ECuBnSEo3W7UZ1w2TCHUTUXU=; b=uEpcDmNwu1mi5h1VU1dNrbl4f3vSKp8cOvrzNy60RGl0hlsyZO7Rs4xqSgkV3vyP7s TZIt1nIuVJYhhudlzcmVlzqKoIzKBI4D1r9oDS9DhbM45BosSqxV1bx84Bx5DWQU/SSL 7K9ofFQoV68FxcMdF8SQnbxJ+BlyDRheYs05hgNvCUdvSYFOdbiMastUftLOvAt6tXam K3u8/CIo5qcZgmjsaWMRiyB0wQZJsOc6vwKWWQ11CR/BcJwZxBFNWaEFIFDNr9Zu+KnF 1tPTea39YKitiMClULSmCeOaMz3tDz+Zskv5c53JipIMDtWhxpVY/tBikvxVNaqXSVwy 8dJQ== X-Forwarded-Encrypted: i=1; AJvYcCWUUdb/zYpKSU5YTUJgAROcYWwVrf4bmIwZw2VAEATVVi34G6cUwVIm/Ioh47ib1rfrnF0WuSpwYA==@kvack.org X-Gm-Message-State: AOJu0YzH+hjPBDu4t69lfU0NJDet+QRfZq5vsBIE/O1hEfO05Xh6/wRK Iq5n33ZrsL4sx6IpA5NYuloeYA8yXrp6nQ/uUhaAyEUMKJJdRCa4zs8/RVwfA1Wh09Ax5UpxuWq opTFramtUOw/vjUSa6GRnfIV0yWjdSbYs X-Gm-Gg: ASbGnct+Qm+lRDnHHKBrLPimdCxM7GX0yPZeVxP4Otru2AveIQEN3o0GYCu9IMOp2UF LDWYbHsn8Tck+Asq9Lo1BWOD1UDnRTm/x4qsB30tGi967O22Rrhyp6gVqdA3uU0USb1WNNXO3Yr 76Da5C0ihYaAPyMEItxCZFgmQnjseNzb0Z3P8BiOxQF5EBTLpRhUtWDIENjg== X-Google-Smtp-Source: AGHT+IH1LLSAI/+s4Zi9zEGfRKSLEY80Xhq1yNJSxRKUtitCQBu1/cEDGmenPOC3lpC07sG6xvj89oLC5RUraLQQ57A= X-Received: by 2002:ad4:5945:0:b0:6e8:feae:929c with SMTP id 6a1803df08f44-6ea2dd25b7dmr6779506d6.21.1741627861048; Mon, 10 Mar 2025 10:31:01 -0700 (PDT) MIME-Version: 1.0 References: <20250307120141.1566673-1-qun-wei.lin@mediatek.com> <52896654fa07a685707b11cfcc141b038a13b649.camel@mediatek.com> In-Reply-To: From: Nhat Pham Date: Mon, 10 Mar 2025 10:30:48 -0700 X-Gm-Features: AQ5f1JpRFqqTBM7MTZvYEz_bClOJNrcAPr9qIUA-7zONYB5oqdusO9tVlggAxPY Message-ID: Subject: Re: [PATCH 0/2] Improve Zram by separating compression context from kswapd To: =?UTF-8?B?UXVuLXdlaSBMaW4gKOael+e+pOW0tCk=?= Cc: "21cnbao@gmail.com" <21cnbao@gmail.com>, =?UTF-8?B?QW5kcmV3IFlhbmcgKOaliuaZuuW8tyk=?= , =?UTF-8?B?Q2FzcGVyIExpICjmnY7kuK3mpq4p?= , "chrisl@kernel.org" , =?UTF-8?B?SmFtZXMgSHN1ICjlvpDmhbbolrAp?= , AngeloGioacchino Del Regno , "akpm@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "linux-mediatek@lists.infradead.org" , "ira.weiny@intel.com" , "linux-mm@kvack.org" , "dave.jiang@intel.com" , "schatzberg.dan@gmail.com" , =?UTF-8?B?Q2hpbndlbiBDaGFuZyAo5by16Yym5paHKQ==?= , "viro@zeniv.linux.org.uk" , "ryan.roberts@arm.com" , "minchan@kernel.org" , "axboe@kernel.dk" , "linux-block@vger.kernel.org" , "kasong@tencent.com" , "nvdimm@lists.linux.dev" , "vishal.l.verma@intel.com" , "matthias.bgg@gmail.com" , "linux-arm-kernel@lists.infradead.org" , "senozhatsky@chromium.org" , "dan.j.williams@intel.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspam-User: X-Rspamd-Queue-Id: F2F48C0017 X-Stat-Signature: s3yee5qc4jo7bq4rpkbb68ppdhm58zft X-HE-Tag: 1741627862-935896 X-HE-Meta: U2FsdGVkX1+L7hJHT8p13IYQAhSB5aY/ftxTRuGhCaf82tksxYflf60Ut2sMkWYDoHHk1tuKPFBDAGJbsdX1iZ6MtzMZ5a4xCbntLB3rhjKB68sb3Hv7zijZL8ynbvTTudYWow1Hu4powRuNouLfFzn6S1eT06LCAonFEFgD4+QfnFR2d5qVPU9MSy6ZrZfPH3UPhxuAX98f5QrdT/InV7PwxOezqHxPGqE5Evdeys9+MW4RnIY30DEZ6JoaYSbrTyhcrzbujQaOhsFD0Jwaxa9NPUnmuuGYSgRiK0T4LdhUtr1aZNKcT+C0Hek3JwUFsfMzaN8mBCSox1Xh4RRtsvHBbrK2iaVloYJkfD93o7kTr8T+vu17uTnlB0qYIYqVhg/jgaayQ2P5oX9pLRZdSzFyhZuuZefmSu2tUF9eY0ZGzYY1iGpXBF831Ze86HY9teZPNYnWLwwnRugaptnugP4Kp2ds2EI+ITGtpqYAMOF1u96hD/pgm49j0osc9JsoelqygTCmKknXmK8fXewIlZ/C9pWLjzeU/IY7wzLMrLHwLLxM7dwcSn7j7YcwclFVeaDVUFCtzyZo1YhS+7JsqhWRevQcIQrHryaFskiOjSdX1Y7gCfHRAah/3UcRXKuQmrKdEaVoXrsJCIjT9zrqyyE1JzG2aL5RtkBNVd42MS7FRBHwh7NDx0zA1blZwrct7qu7/yjzBUZwp0iDjQGz7Sf7sheCVhg4li02H6OS2HKvFXHvlrZtVpHsifv1if+OaNv+XU2C+xEFE3+SVTOx/1UdurptOu6UIjxSqIeCkWkROz+ye40QE3Rk/3SfZOnARupnECbZd/H3Nzytb+jdSbiGCcI8m7VwhMJ91DJt0KYvDHpTPuhKTZdWybZP5yVriNBGjB/fGz/oknD5laEia6XnDvXqHJgshTIAB+fTxyRsuZu3fijq8dwFRM7/jsBM9k9rJD1h8O3LWja5NE0 wJCJcrrw NwSPxxcm3U/mQuCtgfsElp9a6KHEOHNYH27NV8X7GBIFQQ1DrhN5nPZvm0y2vBMEcTE5CYYKKC/5wjOJLVSMzWzmV4QkScpZs0Zc5tyqwwiXR+8DrEr8Ja1LT6Nc/mYYuJRaVJy7shYTOXz9hwszcoexolQETs0Gd2UgVSkgB5zXuPksNMshJ7DHFcgjWYWDydTg8udE2QcXjjx5LOQDM0Psf7fhiAkOdAu9wcHV11T8OIVYHzf1RO06fm1zqa/bjnDt6EpiMQ6G8p4Oy1ZH54f24VMSxpeWMkD6Xa+aQ6BEls24XF1PEK7OoO3/RT5tle40+tfX4bqG9hUT0b3WzOsoMmd7DnMqcSS+mxgZLjlhZaWMYRKbz844NB2Y+RX5t7BmCYomE1CWogKVmrKgBEvSa8EXaMF+lncWisV1rSFqDUmPZzneB4w2OrpZCJ4DtsaCRecU+3Xr6KrnWLoCj8BpTEIoW1e2u4y06 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 Mon, Mar 10, 2025 at 9:58=E2=80=AFAM Nhat Pham wrote= : > > On Mon, Mar 10, 2025 at 6:22=E2=80=AFAM Qun-wei Lin (=E6=9E=97=E7=BE=A4= =E5=B4=B4) > wrote: > > > > > > Thank you for your explanation. Compared to the original single kswapd, > > we expect t1 to have a slight increase in re-scan time. However, since > > our kcompressd can focus on compression tasks and we can have multiple > > kcompressd instances (kcompressd0, kcompressd1, ...) running in > > parallel, we anticipate that the number of times a folio needs be re- > > scanned will not be too many. > > > > In our experiments, we fixed the CPU and DRAM at a certain frequency. > > We created a high memory pressure enviroment using a memory eater and > > recorded the increase in pgsteal_anon per second, which was around 300, > > 000. Then we applied our patch and measured again, that pgsteal_anon/s > > increased to over 800,000. > > > > > > > > > > > > > > > > Problem: > > > > > In the current system, the kswapd thread is responsible for both > > > > > scanning the LRU pages and compressing pages into the ZRAM. This > > > > > combined responsibility can lead to significant performance > > > > > bottlenecks, > > > > > > > > What bottleneck are we talking about? Is one stage slower than the > > > > other? > > > > > > > > > especially under high memory pressure. The kswapd thread becomes > > > > > a > > > > > single point of contention, causing delays in memory reclaiming > > > > > and > > > > > overall system performance degradation. > > > > > > > > > > Target: > > > > > The target of this invention is to improve the efficiency of > > > > > memory > > > > > reclaiming. By separating the tasks of page scanning and page > > > > > compression into distinct processes or threads, the system can > > > > > handle > > > > > memory pressure more effectively. > > > > > > > > I'm not a zram maintainer, so I'm definitely not trying to stop > > > > this > > > > patch. But whatever problem zram is facing will likely occur with > > > > zswap too, so I'd like to learn more :) > > > > > > Right, this is likely something that could be addressed more > > > generally > > > for zswap and zram. > > > > > > > Yes, we also hope to extend this to other swap devices, but currently, > > we have only modified zram. We are not very familiar with zswap and > > would like to ask if anyone has any suggestions for modifications? > > > > My understanding is right now schedule_bio_write is the work > submission API right? We can make it generic, having it accept a > callback and a generic untyped pointer which can be casted into a > backend-specific context struct. For zram it would contain struct zram > and the bio. For zswap, depending on at which point do you want to > begin offloading the work - it could simply be just the folio itself > if we offload early, or a more complicated scheme. To expand a bit - zswap_store() is where all the logic lives. It's fairly straightforward: checking zswap cgroup limits, acquire the zswap pool (a combination of compression algorithm and backend memory allocator, which is just zsmalloc now), perform compression, then ask for a slot from zsmalloc and store it there. You can probably just offload the whole thing here, or perform some steps of the sequence before offloading the rest :) One slight complication is don't forget to fallback to disk swapping - unlike zram, zswap is originally designed as a "cache" for underlying swap files on disk, which we can fallback to if the compression attempt fails. Everything should be fairly straightforward though :) > > > > > > Thanks > > > Barry > > > > Best Regards, > > Qun-wei > > > >