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 0546CC282DE for ; Thu, 13 Mar 2025 17:33:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0595428000E; Thu, 13 Mar 2025 13:33:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 00880280001; Thu, 13 Mar 2025 13:33:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DEBA928000E; Thu, 13 Mar 2025 13:33:04 -0400 (EDT) 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 BF816280001 for ; Thu, 13 Mar 2025 13:33:04 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0F3031C6B2C for ; Thu, 13 Mar 2025 17:33:06 +0000 (UTC) X-FDA: 83217223572.03.68461C3 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf22.hostedemail.com (Postfix) with ESMTP id DEE8EC001C for ; Thu, 13 Mar 2025 17:33:03 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=glfl0tST; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf22.hostedemail.com: domain of minchan@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=minchan@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741887184; a=rsa-sha256; cv=none; b=oQ/r9NGS2tEJFshlyNiuNJqb9YYPWm56M6OSiTXu/m4BANR3ZG/xwnlKO0mCmDv/P5smhl 9vP6Db3Zw1hGipITNdt9p5/U+BwnZB4oNzEmPqb+K07gdR0MIuRiiRrKCOrf9M9KfWSD8i 7dr+l9FN+mhNsJdoXIbzxnIwbCPweCY= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=glfl0tST; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf22.hostedemail.com: domain of minchan@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=minchan@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741887184; 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=21WuzUt5Ju1Izhrm+Sfoym710/ntJSEGJipzNuRdFBQ=; b=KttIZxrVFXYjnM2IFQbck3/crNhnJGcjaxVmw8Db4ZeaTkahlLXocfQArQ/l6Mpu3GOjEl PXex7Punu76JsfWthiDOJUkIqRY0Pgll1IxZ1N1eQ9EBRHStQSn4t3yxnwrSyCQ+6xBVdm JPNfLnYOJclNs3l3sRjoImMibEgbXO4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 2472D5C5FB5; Thu, 13 Mar 2025 17:30:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8795C4CEDD; Thu, 13 Mar 2025 17:33:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1741887182; bh=KufBf6SNVV2/+3f+j7cVUdlgE/k57oz+yacfQZgVu0o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=glfl0tSTDarf5KmqF2WaDKQ2aRgXTC2tuZCMgPixsObeC0jAFrgN3rInTUWfn0763 IbTUdLElP7hTrnIqxhoBOjbuQXmNvzO62AXUJpkcz7ojHEH0Qq552EN6lP6+5kKVyO 21XKi5XV0757FEkmF1hVr4jd6GhrGaVTCaCeieCwv+wcygHRTVyzpNB879d6cmtUqG 2XEPCXesdn3A0vr6fnke/W1ltXLgodm8hgyjYbkS5uwwIrVXs0feJbcqowtqo1ahnP H9qaMyKjyptQvO5fkVzqDZuvO7MC82StGOKEqbR7pykgPK9Zy85yxzTBBaKBG4Lvkz 6MfRNnXGGfTqw== Date: Thu, 13 Mar 2025 10:33:00 -0700 From: Minchan Kim To: Barry Song <21cnbao@gmail.com> Cc: Sergey Senozhatsky , 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 Subject: Re: [PATCH 0/2] Improve Zram by separating compression context from kswapd Message-ID: References: <20250307120141.1566673-1-qun-wei.lin@mediatek.com> <5gqqbq67th4xiufiw6j3ewih6htdepa4u5lfirdeffrui7hcdn@ly3re3vgez2g> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Stat-Signature: iffud7ir6brftmrumwnisui8dbcnbqry X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: DEE8EC001C X-Rspam-User: X-HE-Tag: 1741887183-947293 X-HE-Meta: U2FsdGVkX1/V79Hmy6pPfEnEIXN2FpqfKaxll7fkhhkxFh2FalOIRw2XoDMhsrwQZppzxCP8w9yIhlBVcdGSxGNc1JIyVmZ6/DHgq7bCeJsFsmKaXXDQlcLOqX2fKS3CaXuh86NN3ig9TuSrb01dis1/3K1BS3b5O0ikP5Fr0bF/FbU5+V4O4izbAY4Gc0ChAJ9u0L1187AGb37BPXGrvoF55h+CwHC6PvMN4QFruYiVIC5A0jXQwtw59UOOYB6XA/8q3MesDhDYei0DaYrguW6Lh/vcwhjtWP4GF+jW1otwmnGJjkACoGZGqxv5bNpz4VdoYah0pt7CcGiwDuZc3Hyn6yut7aayKPZpI1svYvyHXZWHWiH3rzOs31FKUhz3xcgLrz2Luxk44iknbFQloLLhWezCPiYbCnbPAGznMvWtIh1ZAv7EqyoGhn+l+iE7MTlrw/2q73bNBPGXybE0goA2Rz5jVeE3U9y1iyEDATuDhc75nVtBXmpeaSEMxSUpKRcbC1279vUuLQmK1DOfvxhlu1QY6oqwz7SjYGq13CZ4hrkpFEuoKJAB/n6F8riASLI4sSJmsEEL0YB2lOeq2Wsw/z4PQ4MPpIBgJpcQziK8tmafido7+F+gfLwpleeEnYmkKPos27s2sdK94Fib5i3ftEHsfTucnijDsdGGzB9eEJ8jWW+69OVkOGOxHiGrSWQ41xqKMMEX1CuR0o9WjQItSfYAjLPbMWbKtdwpRJCPo/qoVm+0SnX269vP8iV6oOyB8zNsbuVTiITtmI4x79rUnvi2BiMYktY3MfPWBNJmVVBZIH6Bz3LInaxZBM70ex0RFAQhQxBsVi7jWPAgP9NZIomV+7DzvAVgK+H/VamoxPN2oN7q3/V3DXwAvh4qVoJDEYlX9DthYrT33JbiCIEO/AoebACYjXU9sM2Yabh4ITpB2tJ98v/J9PlsYkFScRApZtbkW/MgVw29HcL OWGpwSzl 5JFWDfu7IspwAuwPeLKVv/nArHYjBir/L8wqp7FUGTfy0o/71Z51Hy8fxSHSs34+C99G2LBggvJwov5W9TzW1uiedhfCsUpyaFzwuAkzVZBEZIxCpfdBUXjAKK04ojVCig9dcgK+/BvpbTuRbVO1tK5eFqNmjxqnxGZx0v1i4HmctKmIlALe1pVJt8rGxrK7FDgPBmJwNatVgEyh8LlcNwyZ/QxcpWPBrRR90+C1V3KyMFaHeDRa7atcW3qgRAQGaI6Ysb6rxxkvv6Yak9ERg/RRk5eaPI5YqqYvOdeFLah8Sls8L5AeBqz5FyObab30diHPxNRa84Dy7j2JG9gxUjrumlXkIpOdy830SB1VRNLCpcF3Ihh6vWPgVxTWWh01nAtl2JN3fOH/J2mM= 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 Fri, Mar 14, 2025 at 05:58:00AM +1300, Barry Song wrote: > On Fri, Mar 14, 2025 at 5:07 AM Minchan Kim wrote: > > > > On Thu, Mar 13, 2025 at 04:45:54PM +1300, Barry Song wrote: > > > On Thu, Mar 13, 2025 at 4:09 PM 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 compression > > > > > > into distinct processes or threads, thereby reducing the load on the > > > > > > kswapd thread and enhancing overall system performance under high memory > > > > > > 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 bottlenecks, > > > > > > 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. > > > > Then, how handles the file IO case? > > I didn't quite catch your question :-) Sorry for not clear. What I meant was zram is also used for fs backend storage, not only for swapbackend. The multiple simultaneous compression can help the case, too. > > > > > > > > > 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. > > > > Why shouldn't zram be aware of that instead of just introducing > > queues in the zram with multiple compression threads? > > > > My view is the opposite of yours :-) > > Integrating kswapd, direct reclaim, etc., into the zram driver > would violate layering principles. zram is purely a block device That's the my question. What's the reason zram need to know about kswapd, direct_reclaim and so on? I didn't understand your input. > driver, and how it is used should be handled separately. Callers have > greater flexibility to determine its usage, similar to how different > I/O models exist in user space. > > Currently, Qun-Wei's patch checks whether the current thread is kswapd. > If it is, compression is performed asynchronously by threads; > otherwise, it is done in the current thread. In the future, we may Okay, then, why should we do that without following normal asynchrnous disk storage? VM justs put the IO request and sometimes congestion control. Why is other logic needed for the case? > have additional reclaim threads, such as for damon or > madv_pageout, etc. > > > > > > > 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 > > > > I am not sure that's a good idea to mix a feature to solve different > > layers. That wouldn't be only swap problem. Such an parallelism under > > device is common technique these days and it would help file IO cases. > > > > zswap and zram share the same needs, and handling this in page_io > can benefit both through common code. It is up to the callers to decide > the I/O model. > > I agree that "parallelism under the device" is a common technique, > but our case is different—the device achieves parallelism with > offload hardware, whereas we rely on CPUs, which can be scarce. > These threads may also preempt CPUs that are critically needed > by other non-compression tasks, and burst power consumption > can sometimes be difficult to control. That's general problem for common resources in the system and always trace-off domain in the workload areas. Eng folks has tried to tune them statically/dynamically depending on system behavior considering what they priorites. > > > Furthermore, it would open the chance for zram to try compress > > multiple pages at once. > > We are already in this situation when multiple callers use zram simultaneously, > such as during direct reclaim or with a mounted filesystem. > > Of course, this allows multiple pages to be compressed simultaneously, > even if the user is single-threaded. However, determining when to enable > these threads and whether they will be effective is challenging, as it > depends on system load. For example, Qun-Wei's patch chose not to use > threads for direct reclaim as, I guess, it might be harmful. Direct reclaim is already harmful and that's why VM has the logic to throttle writeback or other special logics for kswapd or direct reclaim path for th IO, which could be applied into the zram, too.