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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A87BC4167B for ; Wed, 29 Nov 2023 10:17:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232905AbjK2KRl (ORCPT ); Wed, 29 Nov 2023 05:17:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51188 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232895AbjK2KRf (ORCPT ); Wed, 29 Nov 2023 05:17:35 -0500 Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2a07:de40:b251:101:10:150:64:1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 86B2C1BC6 for ; Wed, 29 Nov 2023 02:17:36 -0800 (PST) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 00A7221999; Wed, 29 Nov 2023 10:17:35 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C003B1388B; Wed, 29 Nov 2023 10:17:34 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id G8u2Kr4PZ2UnBgAAD6G6ig (envelope-from ); Wed, 29 Nov 2023 10:17:34 +0000 Date: Wed, 29 Nov 2023 11:17:29 +0100 From: Michal Hocko To: Minchan Kim Cc: Yosry Ahmed , "Huang, Ying" , Liu Shixin , Yu Zhao , Andrew Morton , 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: <87msv58068.fsf@yhuang6-desk2.ccr.corp.intel.com> <87h6l77wl5.fsf@yhuang6-desk2.ccr.corp.intel.com> <87r0ka64v9.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spamd-Bar: +++++++++++++++ X-Rspamd-Server: rspamd1 Authentication-Results: smtp-out1.suse.de; dkim=none; spf=fail (smtp-out1.suse.de: domain of mhocko@suse.com does not designate 2a07:de40:b281:104:10:150:64:97 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=suse.com (policy=quarantine) X-Rspamd-Queue-Id: 00A7221999 X-Spamd-Result: default: False [15.00 / 50.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_FAIL(1.00)[-all]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_QUARANTINE(1.50)[suse.com : No valid SPF, No valid DKIM,quarantine]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[]; NEURAL_HAM_SHORT(-0.20)[-1.000]; RCPT_COUNT_SEVEN(0.00)[11]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(2.20)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; BAYES_HAM(-3.00)[100.00%] X-Spam: Yes Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 28-11-23 15:15:08, Minchan Kim wrote: > On Tue, Nov 28, 2023 at 03:05:29PM -0800, Yosry Ahmed wrote: > > On Tue, Nov 28, 2023 at 2:45 PM Minchan Kim wrote: > > > > > > On Tue, Nov 28, 2023 at 11:16:04AM +0100, Michal Hocko wrote: > > > > On Tue 28-11-23 09:31:06, Huang, Ying wrote: > > > > > Michal Hocko writes: > > > > [...] > > > > > > Right. On the other hand we could be more aggressive when dropping the > > > > > > swapcache. Is there any actual reason why we cannot try to folio_free_swap > > > > > > even when mem_cgroup_swap_full == F? > > > > > > > > > > If there are plenty free space in swap device, why not take advantage of > > > > > it? > > > > > > > > Maybe a stupid question but what is the advantage of keeping around in > > > > the swap cache? > > > > > > If the page is shared, we avoids addtional IO to bring them back so > > > swap cache. > > > > I think this case is actually necessary for correctness, not just to > > avoid additional IO. Otherwise subsequent swapins will create new > > copies of the page, right? > > I think if the page was shared by MAP_SHARED, then, yes. In that case deleting from the swap cache would fail because there are still swapped out ptes, no? > I think if the page was shared by MAP_PRIVATE but CoW(e.g., fork), then, no. OK, but we are talking about a memory pressure here and evicting available memory. So what is the actual cost benefit model here? Is it really better to keep swapcache around even under memory pressure if the CoWed page could never be faulted in? -- Michal Hocko SUSE Labs