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 14950C282EC for ; Thu, 13 Mar 2025 16:07:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 12421280004; Thu, 13 Mar 2025 12:07:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0D32A280002; Thu, 13 Mar 2025 12:07:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EDDBB280004; Thu, 13 Mar 2025 12:07:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id CEC82280002 for ; Thu, 13 Mar 2025 12:07:48 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 97F98523FA for ; Thu, 13 Mar 2025 16:07:35 +0000 (UTC) X-FDA: 83217008070.29.5205BC6 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf09.hostedemail.com (Postfix) with ESMTP id B0A8F14002F for ; Thu, 13 Mar 2025 16:07:33 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=UjKy5Mzq; spf=pass (imf09.hostedemail.com: domain of minchan@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=minchan@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741882053; 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=MKQlPBogcw52MPx0HPf6gTPAdV2ZIbKmRy+k7i7XGCU=; b=mhHc1Yv9G1ESivdNhKtFiuza4usZMblFylCpWgo+LOhWEd9FjEbzfphR170+y1P7ttqJqt OfWx7jwJWp2Le8gQOPnlvX8wgqVqM6s13E0Mvwaig8xKJg/OjW+R2hciLekoTquTsiPqCp L71bVItjT/6LuEv3JkBwkQgFpyfl8Ag= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741882053; a=rsa-sha256; cv=none; b=gS0DRX4AhBbiyzQoZbidaqnoV/mthjIm7lhNQH2jkU8u8dDIVtPlxR/cPaG0J8naAtVqdU YLTjvrVEVvTaS0v3Vn+8SqKnT2lY/v07c3O4FskZcjm4FYmDXm6KbtOLY2flySDD5n/c9E 6x0wh8/T/Si0nKTjr0LLSuWyS94J9bQ= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=UjKy5Mzq; spf=pass (imf09.hostedemail.com: domain of minchan@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=minchan@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id CCF8AA476CC; Thu, 13 Mar 2025 16:02:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A13F2C4CEDD; Thu, 13 Mar 2025 16:07:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1741882051; bh=BQXFOxNso8FIR8jzDbLHKPtOvTBzr+ixEF9OdVlcvsU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UjKy5MzqzIf+Yh8yvIA5cYhQvCRvJOMZGRgCouhY4XQbqEPhgnpvqfobojD4k3n12 wPZl/IJFvxCMgknbhUHC+PUev3Ir7M5Nui+VNqJaWgxmhq8wH6oM576OYZdo8TCy3r 8jyrewO1JtE5lPWCVMoJCbFdZPhfzDPFlU5DxzBUq2kVXaupL89bbPA/R7b7owqkcP 9Xo/T9lSdTEOGxVaomzVn47eKegUTlGozpbyswaqQH7fTy1maVjz7LnbGNj+lF3JE9 A3L76Vy6ZidOs89C/z2g+3iPgSIemcEcrtz7AsPycCV8qmThcg/FZuqazBQ7P5ckJO TOm/z9TRq2JZQ== Date: Thu, 13 Mar 2025 09:07:29 -0700 From: Minchan Kim To: Barry Song 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-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: B0A8F14002F X-Stat-Signature: 5whzftm7qabpx77yig7g1yu6t8byui9y X-HE-Tag: 1741882053-228164 X-HE-Meta: U2FsdGVkX1+IEraWNCMJSFjj8syrW0jAia2YkU/mZa6zkOYdw+jupeSjetbuD8WZ81prxCJkiCPYbQbaqL+wjPRrAvuea26uyyx9NmGHPTyAN7sL9nM8VF0CPQj4QIueTEiyBzEGsrrsYZ1m5/KCsAdD0y14tAvSA+VbmwgZY2fvjXgXHjlTViBwz77+nWmqLRkWeZdJuJYvCBraR9yvknf1QM525n6wwdHK6Qv0sA64qOAGmKxGPVQR4bxnRuHQbzRLdfreyzCiMaVRWwvuK9ItdJO6SKf2BYQAn+12N/WktPhK+ku7mUNV2LCipDyjNMtZ/Hegz8any7Di+MNRWiPJgi9oQ7Z7glMIU9+we8s1/X2niukRmPeEmblZZlpTgkGc5q7rBRQk+E+4SwetPDRmv3PVQI7C23t/DwBMgmT81EQMru1mCEtu51hCxpl8YGlniwhm/eTgAyHh2e2WQQQVlm1HNnw8r3PQ/NKaIwx7gSGQ7G4706hXpRXhqIqCiiu9fhS8DHFWebo7IRzhJblrvgY8t+FjtX2EyJYG12Bd9E2TCcunZvO1kfJEqaq95VOdmp4BK1/8/i7b1bo7O3kCXqGv7/A962MWTVtC2aGQGrZLYW4MNgWrjPrwlsuRm97k8oOUqL4ELfGbRRjfb5/E3IFNj1GvALueSW3BAoim+dlz4/T9Fs018juwigsmJfSwTwzXdXBFIvOTWvrsJZAHLHD8tVXFmyYhh0Uy8EF/N6hTOkuKEvRyVgkJ7MFXzhwazVbbjHnkp1cXbq8NqL83NgTRWfqBh/xrSrnhpszhFjB++ICHjXw9AATWYsNxHpLoc2ZofkPGgSJ/AG296g7gykMuEbW40vNgj9gLi2hY8VVDwMwl4smbmGnxw/Oz2nub9vYDyNmoJ10GLuQWOo7KupCDIvoplPSqy9W+Ai7f6nJUdhwyzvMcw9OutYgzbRKw3FFNMN38zvxcQCr rhu3lIw/ +HEfl1XntauFvzNbwVe9quj3DUPCTCBdlVYYGKhRRoJaghkl+bfKSO1fZPPxxzYxh+1dbpw+E3JrM2pOtaOKqwZxtMR7bXh++KryX+qNU0XE0T6Om8vvPppAdBGXfyGu6zAE1tuBqF622NkZYqmHh1ZMP3WiekgXGAMV8fe4G/Z+mHujy7qIG87HAB5aOq80g7HHcNy+XMiuNZwSDeIynSddxSfWqwaMpEn/XxYDKRkejq5yNQJJ1P8Rgr+bzdLjdCipKtyWA0fQlavMwsU+6tg7wxt7axFReqid7IoXGLbEXi/1rPo5ZPJ1vXjXPPd0KSFK2eblQpfcQ0q6u3Ck3Kf0sRPpW4VcjmOvfXyXoY7zok1/fgJ0Xtf/YStefxS7ACGyZKFnOdtPtu5NQPFWaAoWhWA== 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 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? > > 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? > > 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. Furthermore, it would open the chance for zram to try compress multiple pages at once.