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 2F91EC282DE for ; Thu, 13 Mar 2025 03:52:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5B68D280002; Wed, 12 Mar 2025 23:52:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 565F7280001; Wed, 12 Mar 2025 23:52:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 43065280002; Wed, 12 Mar 2025 23:52:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 2450E280001 for ; Wed, 12 Mar 2025 23:52:36 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E8122577D2 for ; Thu, 13 Mar 2025 03:52:36 +0000 (UTC) X-FDA: 83215155912.30.D4BAF03 Received: from mail-ua1-f53.google.com (mail-ua1-f53.google.com [209.85.222.53]) by imf07.hostedemail.com (Postfix) with ESMTP id 1D9374000A for ; Thu, 13 Mar 2025 03:52:34 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Q3NhvdLr; spf=pass (imf07.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.53 as permitted sender) smtp.mailfrom=21cnbao@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=1741837955; 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=Dixt0o39GPmiD7R1LFsj4ci5HN2s7q23k30NE+Mi48k=; b=PR7DuHdPOQg5OYJvZkZvvc+LgXi14SfXtVdhNRTSKqWIah7m8LApCcwAco3mmRSmkPY/7W +zvl9sEIKtaCHVRCrS/qqZJiIPemlGivtrz1gkvhs3//Ckh12/k3zjw1ZIUC8Z6/yqH8gB tMAGrgo80vFakpPGgKL14i31uR9jQMo= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Q3NhvdLr; spf=pass (imf07.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.53 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741837955; a=rsa-sha256; cv=none; b=rU7vJQBrCxT4t04p+RLRBIJgIOq825tg6uKkQrb7sFZN3Lk1zIPiW3pAKY1joC9ego8uOV qGcy0O/cS5//NPiOf6QhnWnEaqUX/0j3W9XQBZUhblYxqPQMiuImvoN53AsSqmrMgAobSE eh5BnbVjlCez0OFWS3K6dPj2lqbUQqg= Received: by mail-ua1-f53.google.com with SMTP id a1e0cc1a2514c-86ba07fe7a4so436554241.2 for ; Wed, 12 Mar 2025 20:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741837954; x=1742442754; 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=Dixt0o39GPmiD7R1LFsj4ci5HN2s7q23k30NE+Mi48k=; b=Q3NhvdLrwlgnxjhE1BjCFyLxwb+uEkFeB8RP2ovFWaqV2aHkBlnjxgexHOrVEoI/JL fhAYHGtHWb0oMxrOU+0wSzxSY6a4AdwziP8OqwXsfsmo2HifPgKuQHqmxSgx7EB6zq7I DfKJ8lPyy8g8hzoFy2GuLwNR2qPBNF/ZIEbN58b9HGvdza9lU4hjzmi0WueP+kYy0eH5 bo93Kj3SMr6k5izX75MC8e1ASD1e1CIyET7NyaraQokOrWV/cDvta1squvxzfQ6qlSYO hVVYCwEPsWHAkYcayjrWQ0dgIh8bumsNbuf9xhStYKHPN8vZrlzbi+svRR77tGMaeFiS DQAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741837954; x=1742442754; 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=USOYwjHz0sLwCaf3VCWaanrgQP6Y93tB4tbYNBn6fgo4SLuyeJmEDT5dm90ZEuIV2n CSzVss1udmvicAtdXX1hFb5W0iqX9cXWq6pZstl50ASOgS3bFXpErPNhzRB8VC25uYj1 whOo7NJQVxgLn3+tht49R7l2APmaNtxKAndNeDQ3TzcMzQgRwecX8tBvJcUybOVkrllb HYRKfxlQgOQ/KYT3PCmw3Yc91k29w1AcM02EMNZFvMp73lmIPJ6K5PtKHLZlmKm3OkSq NT/CVnpO8AhyYwSphFUggSUa2zly4Mk8CNNjTgIZy/gSidt3oojsdO9eUCuB9ACP1zSz dpJA== X-Forwarded-Encrypted: i=1; AJvYcCWfGtaEH+b0Kxmg5VbX41BkNsd4s3Ekwn4L9IR6kvy33SFDVu+jZeYNV0WI2LjDPyVc6b2ci/5oRA==@kvack.org X-Gm-Message-State: AOJu0YxurMJiBlzu8Ez31VGGtddF2nwi7o2fl7ybYzNf/M8saw7oTbPL olbhFdkZFL0B5JBQ9m/TESnlUhCFlCkzTCi0J13Nqr5w857Qpe9NUNwIb3hUYawKLXjEDnAtnhh qaIwTH4i/MqOQ6IGEciOkLsaSs3A= X-Gm-Gg: ASbGncuZ1ke57GcuVGyIQllyR+id9PzSBDOMYc5K0F7A+wvpUGySUy4+jRxUpoyJw1m 1cRJdW97NkAFvXBeWtMAqqiTabxNQfi453v3N1QJo+dLUvrenWuCP80O+wJqp0DbvTxRclYz4WZ XllKNqoxhUlPHZbGuWcx/+z+KwfKUt1MLi3GjuVw== X-Google-Smtp-Source: AGHT+IElZnLD1RtQvQ1Xa/HL9SBtcFTvUikPJzrreCJkAkwTjpXP1UpN4dl74wMUECd2sr+yNxTt2PDKxbQqviHf2Wo= X-Received: by 2002:a05:6102:41a8:b0:4bb:c24b:b61a with SMTP id ada2fe7eead31-4c30a6d23e9mr19456122137.19.1741837954156; Wed, 12 Mar 2025 20:52:34 -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 <21cnbao@gmail.com> Date: Thu, 13 Mar 2025 16:52:22 +1300 X-Gm-Features: AQ5f1JrExyj5F0Vah_a1_rjhnAnivAK4d453p9csn5RazKNq_dZhJV200JGLGds 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: 1D9374000A X-Rspamd-Server: rspam03 X-Stat-Signature: 4hcimbean9ssfxpwarnzzej6ioepzh1p X-HE-Tag: 1741837954-820894 X-HE-Meta: U2FsdGVkX18Dl/0SbI+GI2UXcXra09YGUgpFZmrpGqQqnC62jAj1N1sxRx44tpjoEfy4A2YrBBu4RkzG6+PmpNYhayQ0Tqt0DQJ2wol11YJfJAPfF6lJpBQrBy93SZskS5MdCSo6annNEQVSRAyruCS2eQDwcUSqTjRjRHR/3s10f+cmKzdIXWNEW7F2F96tHXtahOwZjIBI4zQzwUW5Pm9oDGM3i9d03sxjxPqbMuAn+Da5mFcsLUGJgR8L7xbIIr1pPt7J5SxAP4+nhWPml507NV64I7rqoaWIJbmSMG0Tm3sceVF5zrg6kFPFUP7thpZe9500ynOle5BKCUDFMffKwmjYulxw2HyfHfIDwn6g9VSR0Rwtjras6eRQ2X5F7TZHh/o9nmSiVsuZHYkDPUdWYdvtyrhACoKWGnCehOcZ3jJEV38TUVKLAQfdJqVh6n1sxm9wSna9WR4lbr+SNTO6u7HG5eC9HAW0AZaATwe0NrP8HXiNbHzVVljnZp5OivPpYssjPaCCE4AqbeRXYV3l0JKKjGEpDYNgf0z8myIpJTCedFSwN1aJ5LUyKUKBkPoAgWai3YN/jeaoNv0YlUzlfK2R44hby8mHoCbcQgR5CeX4Mof5nIlZYUpKE7ouD6gwaiGWOOg55HV3Th5weo60JA2bR3oV728urTmv3GXycz/JXzZiol3ToQTFvBlVTsTW+nOgAfxfzOrWcl2jwSOq8/a6CY9rBo5b9e0VkbSb0MtlHzvktfj+pnCUB/YkPhgmoH4Afp/yKW7DNG4TrdfvwXWhN5RjwW2X7RqRcWxnrakU4drWOcdm1e9YxZLi9ebQXz68fgr332hJY3athwSFPpjY6TGRSblOwKkVGvxXu8O+mDDn+K9mYW8j9CsVo2Ct+hM08KQuN448LOUl4AB0V/wG4mJbP4v2KckWpzX3Eivp56V62hVeDxduB/thgtPUXnRROhyDwZANPfr EFy8Buul VWOMQ97AW9xzSyqo56WXjBn95RcxO/e2creyljoJyap0tt2UqXoOxL6R9spLnxpk/4LtDJ4AZIWEQggIby3l5M/+mOiprSXo8F56sIkTezLrrRP36Im+jCnCpW+CiYZocXztLs5ra3P3TmCwfOdTbz+PT89k034I+GZAdfujdMr32VVL3aDbb8/v2fopp3xS55zPN7C3hCeo4dSHVg2zTd/wclSqfZjWDw8y+1YMPn0bo7SpgdR+AGGGAt50OokAmjjIA1LDR5m+gmmo6ncaK0EB6a0El8BjzgdTjNtkkycvZKGGZWUy53BybqT8OXkr3GGzxuwBCpyb6osscVPQOTnuWCTcZnB/PjJQb6q1n14z4sLwmiMAoSezAFPMkrrp/hqBPBydHpAmLG2/boSXpZnYie/Bwc8W3Ds5w 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