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 5CA1DC282DE for ; Thu, 13 Mar 2025 03:46:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 03535280002; Wed, 12 Mar 2025 23:46:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F26D0280001; Wed, 12 Mar 2025 23:46:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF02D280002; Wed, 12 Mar 2025 23:46:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C36AE280001 for ; Wed, 12 Mar 2025 23:46:09 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D8F2A1619DE for ; Thu, 13 Mar 2025 03:46:09 +0000 (UTC) X-FDA: 83215139658.22.11C2974 Received: from mail-ua1-f48.google.com (mail-ua1-f48.google.com [209.85.222.48]) by imf27.hostedemail.com (Postfix) with ESMTP id E292940003 for ; Thu, 13 Mar 2025 03:46:07 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=quarantine); spf=pass (imf27.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.48 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741837568; a=rsa-sha256; cv=none; b=kwZCz6b1wBxil6l+Z1F5E0Q2kUXIhhoe3csvmclE/OynywmQTIBT+AeHDiXcRAe07P+dpX aEXODlyGNi5KLjaAE4iRtozdo6EirX6QfLKlSPTsowV7p/1qmfbo/QKh7N/CV1KtxAqNpX wSEIduVuj9zItl8Inks7YWEO0HuNHu4= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=quarantine); spf=pass (imf27.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.48 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=1741837567; 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; bh=Dixt0o39GPmiD7R1LFsj4ci5HN2s7q23k30NE+Mi48k=; b=d4LVhmihZ9ViuAARqAK3tHrA0lIf+F+Aw2NRp9Ht6hklR4sPgCgIUobAwpg6xsYF1VJ6jb Z6ndxMdq2DOw5UMuCzzeztAR+mXkb1wBDdcL5p2ihlybe8exS54wmWDHwFe0E3wdeyTqz8 goS5qBXZNtvLQKOE0GyUfhAN4jZvjpA= Received: by mail-ua1-f48.google.com with SMTP id a1e0cc1a2514c-86112ab1ad4so214666241.1 for ; Wed, 12 Mar 2025 20:46:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741837567; x=1742442367; 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=Dixt0o39GPmiD7R1LFsj4ci5HN2s7q23k30NE+Mi48k=; b=pnEkLzpSOm1G2IfFUvZ+xr4ANjlEYgzFhjt3tDW15sYe0StvSv5aLYbxnEp+pc8tgU R+vEWyIffkMwpYIuNOtOxY0NsRvLTCQ4MfTIEVYUyhprvRV3ua2Dc7sbChel63Dnv5Ck kEeuwNjsP+YYmagkOUHgcxJetQW3gmJrD80hdfpeAwQuQ3oM5OFlGyqQW2n9vZiuFqi9 IBAqxOKCV9ToqL6K4FopDLk6sSwQfV5z0oG5AhiIc/M2RprJ3dWkkcXFNrREDHWTH6PW uODiZse/9RPtbcjb0iraNiPEsTW5Vf9tZmU7ChtBef+Gs2F6vmYzT909QufRO3FmH3Mo 5ugA== X-Forwarded-Encrypted: i=1; AJvYcCVLUXaLB1uePOqZREYawA1kdpWy/Imbgou46AMdnUqbuE9Fj2Unrs16F65WPwxNvRW4vjjM1yPF1g==@kvack.org X-Gm-Message-State: AOJu0YxpGv50Dc54gDrRJ9jIds4Jyh51ci2yWAJx0WauV6PDQ/VBr9jH k963S82o6BSicMA+qEMgGIHJofCssZhgkyGDF+6JQPWd7zyAdL7tg4Npw1fi70zT4lLzxV4AwJo mSSQ0CyciqWHJBlrejcplMxz+ccA= X-Gm-Gg: ASbGncu1IG32iEDn/tO0m6jB48O182D+2xtaMDSJ9cUZABeefAVQpcxsGxpBJG6m4tf MtzT0hx9cfbk09b7pothUlbtKTvEpH7Q3GoM/8F9FuijhssSP7S2QqKeMcrkbEQkpGJCoDxn43N Oe2ITFBv83Bh0HUg0WLIE2WyNu2Wc= X-Google-Smtp-Source: AGHT+IGKfJC93Nhzdina8J8KkusxalxlfeWj7d8uwv73O0rWMH3p3y24byG1ZqjULZykunz6Axe6UbH9L31TnbSBip8= X-Received: by 2002:a05:6102:32cf:b0:4c1:90ee:823e with SMTP id ada2fe7eead31-4c30a5aca5cmr18955360137.12.1741837566985; Wed, 12 Mar 2025 20:46:06 -0700 (PDT) MIME-Version: 1.0 References: <20250307120141.1566673-1-qun-wei.lin@mediatek.com> <5gqqbq67th4xiufiw6j3ewih6htdepa4u5lfirdeffrui7hcdn@ly3re3vgez2g> In-Reply-To: <5gqqbq67th4xiufiw6j3ewih6htdepa4u5lfirdeffrui7hcdn@ly3re3vgez2g> From: Barry Song Date: Thu, 13 Mar 2025 16:45:54 +1300 X-Gm-Features: AQ5f1JpUJWPRwcbH8KgHq36fZ320naGIJ8qCM44dyq_HWdMuZphdvOhJ0AAxw94 Message-ID: Subject: Re: [PATCH 0/2] Improve Zram by separating compression context from kswapd To: Sergey Senozhatsky Cc: Minchan Kim , Qun-Wei Lin , Jens Axboe , Vishal Verma , Dan Williams , Dave Jiang , Ira Weiny , Andrew Morton , Matthias Brugger , AngeloGioacchino Del Regno , Chris Li , Ryan Roberts , "Huang, Ying" , Kairui Song , Dan Schatzberg , Al Viro , linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, nvdimm@lists.linux.dev, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Casper Li , Chinwen Chang , Andrew Yang , James Hsu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: E292940003 X-Rspamd-Server: rspam07 X-Stat-Signature: mf9biatupdwush9autkou4dxaprhbez7 X-Rspamd-Pre-Result: action=add header; module=dmarc; Action set by DMARC X-Rspam: Yes X-HE-Tag: 1741837567-672596 X-HE-Meta: U2FsdGVkX1+Tnf1KstnRZWICiSAv0GP8/yjZ62Rlul3Z+56ocnv3UsTGWrpCqnzNvei17oqBRgc/CTuy7SgsRvpXmwhENAkh2pzwdl+Xtby+/+NbTarqvYr77jom8qc+gT14L2dMThh8o7rw8nxyhUgCUIrJUSA4VOpYCL0n9bpnHOmWyelO206YMqZsybRYLI289vdeh6/lod0HRxrJTQafTys21J2nRPmO4aES65RlV/Zwk2D7KLbJLT3x5shxwZuWQhhExBe/IPLBmI/4OnDxwIkGgTSjP4dacV9/FvRLX122Kn7FW3J+XpCtreTtZJTmqfZdfuiu9s10g6p6Y0xPMwScqDG1JiwehGpnr0/vRQCLlDPf0l+Lhr6b/UYuE3gBaGhak1X0hf2s1h06+19tFcjrq0mGFV66f4XVVlhVx5tYBDxJ8pSwyRM2vgUYYNpBBXyQTtso/EXVKabdsRAzPbPLsnIgDza1P5UZTDrYEa1q5h3D+Jx2khcQ78whHMYDeVvqPvZceAX1Ar3yzZvTnlYPdMaHNUZprdWLIriP7XEd6SIyUfg3wpHalJZzdFxv3GlPC43Idq+RcaqP2UJjXVaB8DpF3CAtaMUuYtiqJcj1A2MJ7MP16TWvUa9JYKDS6cjjO+s858QX+L0BHJPFgTWZd79Y5bRxcSXUVLl9kzvLFuR47FLfFS0G3+9ghqadHnaPasoQE+VfhRIhVbR4FQRqJKSINRR8cb+J36Or0MHIy+1ohQI3wIMIXiGHNMEvuRl28Fwp9pf4gNt6dgc7d+VnCTAzRmvy6ZpjcWO/NKtFgmUjroV2Dj+jPxrOLSXRaqwfBnrKgggj9TvboZXY6Z1A3PwCsTBzluJiqjeryikvIvC6KYOmPoCU685IxHFQOdi02dV+/3dxWtwprBU3g7uuR0MnEDRTMIhOlKBW+DyqxeFn491boMFRjzZswLkoaHxJUaHgbtmew1P Z32uqkXV oYxlKYYVx9T+9XxAZYUT3aTFH8Ebk/ik59zPUfEXSlABZcqqCy///fTUQobn8JtR7CjPGWxH33jJS5X9jVIlJUoPtHIaVFwRX0Td/UOLm7ZhZMQy24tzOH0y7Hu1e936Pulwnz7SiSaeF/vGOJ71EvxiiAPINZdsK+PWZmgObj9Yg/RX2/8Ztlt7WC7MAc2/QPYjS8N84KzMVj+FnjYtBEW1czfbHNnF5n/GvZ9hP5mmknisZyAmxBJ7YfBrWmkHtTsU6V9NqaZFq3bnSbxt8vASjfXcCXU4OrpFJE7lKe42vLb1FJOOeQb8U/emX79kXde18tfLKbbjOG9uHW6v+1N+5ljORa8DhADtP5ZSqlFq5YS8gGyf9szv0XppVUldncH8X 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, Mar 13, 2025 at 4:09=E2=80=AFPM Sergey Senozhatsky wrote: > > On (25/03/12 11:11), Minchan Kim wrote: > > On Fri, Mar 07, 2025 at 08:01:02PM +0800, Qun-Wei Lin wrote: > > > This patch series introduces a new mechanism called kcompressd to > > > improve the efficiency of memory reclaiming in the operating system. = The > > > main goal is to separate the tasks of page scanning and page compress= ion > > > into distinct processes or threads, thereby reducing the load on the > > > kswapd thread and enhancing overall system performance under high mem= ory > > > pressure conditions. > > > > > > 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 bottlene= cks, > > > especially under high memory pressure. The kswapd thread becomes a > > > single point of contention, causing delays in memory reclaiming and > > > overall system performance degradation. > > > > Isn't it general problem if backend for swap is slow(but synchronous)? > > I think zram need to support asynchrnous IO(can do introduce multiple > > threads to compress batched pages) and doesn't declare it's > > synchrnous device for the case. > > The current conclusion is that kcompressd will sit above zram, > because zram is not the only compressing swap backend we have. also. it is not good to hack zram to be aware of if it is kswapd , direct reclaim , proactive reclaim and block device with mounted filesystem. so i am thinking sth as below page_io.c if (sync_device or zswap_enabled()) schedule swap_writepage to a separate per-node thread btw, ran the current patchset with one thread(not default 4) on phones and saw 50%+ allocstall reduction. so the idea looks like a good direction to go. Thanks Barry