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 56F4AC61D9C for ; Wed, 22 Nov 2023 10:09:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 93CF66B02C1; Wed, 22 Nov 2023 05:09:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8ED486B02C2; Wed, 22 Nov 2023 05:09:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 78F856B02CC; Wed, 22 Nov 2023 05:09:11 -0500 (EST) 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 652CF6B02C1 for ; Wed, 22 Nov 2023 05:09:11 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2DFA1C057F for ; Wed, 22 Nov 2023 10:09:11 +0000 (UTC) X-FDA: 81485167302.24.E5525B3 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf05.hostedemail.com (Postfix) with ESMTP id DB832100009 for ; Wed, 22 Nov 2023 10:09:08 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=djQJDJeR; spf=pass (imf05.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700647749; 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=nYWKMGwFEK1Cr53Cmv/Y33Ufisfs70n1uqzwpJsX9Ao=; b=0Bv7gN6v0Lxis0hsrSBIPMK996TbXc4iLoRwPttkvhKy8rr3hMbG559e6gNVNxkzPTzmxm /cTVDXUkdUxJjfoiWhlDN442MsD5tPGS8UG0wv3+coe1/7SzWD+vnlxpYA6lXKsttKykSC 39TY+Zha4/S4NCBFyNqEHn17HekRnJY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700647749; a=rsa-sha256; cv=none; b=RxfpNPomt2B+dt/vPfJCNzYYwADQtkGennZX7CuIs357xofKZMtLL2gD9LdtcCaGbT62o2 hhHpGK/6idL7Bx4+B3y9DtJ/JbGhHE2g4yM4KQ5BgGfegeFpZrPhPmQ4pyWxMxoqrnwo1Z z9z9uF91xbgp1fToAYPf8Ozokd51+5Y= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=djQJDJeR; spf=pass (imf05.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 23E831FD5F; Wed, 22 Nov 2023 10:09:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1700647746; h=from:from:reply-to: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=nYWKMGwFEK1Cr53Cmv/Y33Ufisfs70n1uqzwpJsX9Ao=; b=djQJDJeR4YrGdnZd8gAgakvooDQgWu1Ah7WjjhLtiCr/7wSBSx67RivxDRfDfmHEWUiOjw Qgr4bV1Tvka4YpIojU8ErorHfRR5FSfqIAz2gqcEPDG0wmLEvx1JgugCyGiPbejnKZIwj4 WvEZshhoeVJHzXd09S9EMPZJkSTLpO0= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 04DE013461; Wed, 22 Nov 2023 10:09:05 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id K/QbNkHTXWWtDAAAMHmgww (envelope-from ); Wed, 22 Nov 2023 10:09:05 +0000 Date: Wed, 22 Nov 2023 11:09:04 +0100 From: Michal Hocko To: Yosry Ahmed Cc: Liu Shixin , Yu Zhao , Andrew Morton , Huang Ying , Sachin Sant , Johannes Weiner , Kefeng Wang , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v10] mm: vmscan: try to reclaim swapcache pages if no swap space Message-ID: References: <20231121090624.1814733-1-liushixin2@huawei.com> <32fe518a-e962-14ae-badc-719390386db9@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: DB832100009 X-Rspam-User: X-Stat-Signature: ymkaxeqf18hbbf6jbkujzx3whgbgr576 X-Rspamd-Server: rspam03 X-HE-Tag: 1700647748-624704 X-HE-Meta: U2FsdGVkX18V0O6TKwttlH1wDASBFkXq52BtrZc/vpBY45zMUNPzfOryO5fGTw1aZXRxRfsD1PkY7Q2DZrY3wA0LOu6vGk+KgEqDm5l518uZojW/MWu2urDYD1rJoVshpNZ+ov3Hr9Ymfk9V7OLVmZ5cCRz6eKy+Y11RdLIv24H9t9nWxs5HBKwPJKJOS6QwF4bpXRexVo8LW+qgB+V9IUeIwbnVVZIJ1Y4wNefptAheOFuV8PH8ZgWi1+I0a0rjWE6V/m3LcSQouch+vUPbxUsJrGGkTQN3dVYGGSd0ZDUs+XKivIn9ti8Vui8RD/1ma9OZGnzgGXWf/Zy5iCZT7oasqiUF1uOXTrscFHIDILdkzioU+NGyC9DHHb0aks2lWwH6rpwLuVcihpyPMVyIx0MourK195KQ7F+uTEy1SxjV/nGq/riJPW5lmEDVYA/GTcFaORGDfPpx4fvLvFpWTkwPr3VZH4Awcx0B6F9qGfheEkI8rpGN2dvBkPXV8rfAIZl7E2rx2T2UvJH/rIs7APMWm4q2DoaEZn49GJsr/kAmTaRB2SvLW9IViIPkkydPAkMg4Phs2MVSAP66ZVH9tZsgxMzaX+U9DF0bKL57zgVU4TrSGp3oEYtHGiVd3ujPHjVLXaGvh5/0iOn+mSKt1JH+O6h46E5n+2O9YO4cVwBL67B+h0/YbcOdTloBqBXZyOKJThzYxrqSaoJ8NEwe/gaz5Obvw4LiOorWT+scjFQl8aDqYRbgyhEtfMsdWnlAdtMn9krJikr0HsPbrN6dm9sizkjuu4JqQfS0rP9d4M94kP36CljznXU4/rbJme8u3tafTTJ6OqAHxumAAVjJRqTguWQMsVB7l2w8CaXhge5I3qUizP87aXQHPOTtJ/X8urobGtQY38xNRkt0zig0GloyaumSVDGlI8u4wQOMp3GcaLyW/70Mpe/GvI/2+feyg33h/53WyxR3LYm4upy 144+sOp1 isH64Ba0qW1bwn3MN1zTr4a1bK53yYt5ElEVDc1LJF1Cbb4o9OQdvjEmmU0E2Vpfvfj9pt3i0Z1qpknVABNSLFIR4y+G6gWBrkq8w321Lu/JLzFlB+7fy6V6Z1OViHGWGduZX8U6un9/0U5iZJGTFNYJXmm7tR2NdeO4/q98ZyFbiSl8mxkS1XUQ6NnBEw+jrH8fKcbDH8tn8JxWonzZ9EJB7iw== 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 Wed 22-11-23 09:52:42, Michal Hocko wrote: > On Tue 21-11-23 22:44:32, Yosry Ahmed wrote: > > On Tue, Nov 21, 2023 at 10:41 PM Liu Shixin wrote: > > > > > > > > > On 2023/11/21 21:00, Michal Hocko wrote: > > > > On Tue 21-11-23 17:06:24, Liu Shixin wrote: > > > > > > > > However, in swapcache_only mode, the scan count still increased when scan > > > > non-swapcache pages because there are large number of non-swapcache pages > > > > and rare swapcache pages in swapcache_only mode, and if the non-swapcache > > > > is skipped and do not count, the scan of pages in isolate_lru_folios() can > > > > eventually lead to hung task, just as Sachin reported [2]. > > > > I find this paragraph really confusing! I guess what you meant to say is > > > > that a real swapcache_only is problematic because it can end up not > > > > making any progress, correct? > > > This paragraph is going to explain why checking swapcache_only after scan += nr_pages; > > > > > > > > AFAIU you have addressed that problem by making swapcache_only anon LRU > > > > specific, right? That would be certainly more robust as you can still > > > > reclaim from file LRUs. I cannot say I like that because swapcache_only > > > > is a bit confusing and I do not think we want to grow more special > > > > purpose reclaim types. Would it be possible/reasonable to instead put > > > > swapcache pages on the file LRU instead? > > > It looks like a good idea, but I'm not sure if it's possible. I can try it, is there anything to > > > pay attention to? > > > > I think this might be more intrusive than we think. Every time a page > > is added to or removed from the swap cache, we will need to move it > > between LRUs. All pages on the anon LRU will need to go through the > > file LRU before being reclaimed. I think this might be too big of a > > change to achieve this patch's goal. > > TBH I am not really sure how complex that might turn out to be. > Swapcache tends to be full of subtle issues. So you might be right but > it would be better to know _why_ this is not possible before we end up > phising for couple of swapcache pages on potentially huge anon LRU to > isolate them. Think of TB sized machines in this context. Forgot to mention that it is not really far fetched from comparing this to MADV_FREE pages. Those are anonymous but we do not want to keep them on anon LRU because we want to age them indepdendent on the swap availability as they are just dropped during reclaim. Not too much different from swapcache pages. There are more constrains on those but fundamentally this is the same problem, no? -- Michal Hocko SUSE Labs