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 1905CC4167B for ; Wed, 29 Nov 2023 10:22:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 931CA6B03BC; Wed, 29 Nov 2023 05:22:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8E2C76B03BF; Wed, 29 Nov 2023 05:22:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7D0566B03C0; Wed, 29 Nov 2023 05:22:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6C4806B03BC for ; Wed, 29 Nov 2023 05:22:31 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 278B6403CE for ; Wed, 29 Nov 2023 10:22:31 +0000 (UTC) X-FDA: 81510602502.23.CC80478 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf28.hostedemail.com (Postfix) with ESMTP id DD312C000F for ; Wed, 29 Nov 2023 10:22:28 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=fw7zhBX7; spf=pass (imf28.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 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=1701253349; 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=z08E1oEubgUv18/fMFXjEfb/IXlpOAqyFntT1non7IA=; b=aVH5rPWTJGgHHbaYehUGAV5q5A9ZjKEwKfWivxEMrFPzzBZZL41R9X9qCoBvx6lPaeQvYc C31FwkhDXdE4UH++kYXwHF21yT1FFg1kGfo3e39KZmK/DgVP0R7AhWJWL2h5R/7HIapyqU 5hkl8mCN/zx6r3hDMF8Yp0nDdz6SOlM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701253349; a=rsa-sha256; cv=none; b=LGtyIDyqtlF1JBgKOT+K9fuP6VK4uPmWN7DwAbgI0c8gR/HTX02WT2ZoAYEKBdDEC57gev tskvoGlM6QDlzj8o3Q+KGRt9z5DHLUthUg1DBa6Mo6qu2ruV0m73ALMuIl1MV6TG079cYw ydKZQIpQbdwR4Fym7nBTCcuGlueJH9g= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=fw7zhBX7; spf=pass (imf28.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [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 CB6A1219A5; Wed, 29 Nov 2023 10:22:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1701253344; 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=z08E1oEubgUv18/fMFXjEfb/IXlpOAqyFntT1non7IA=; b=fw7zhBX7eOmcGkrdZ86sQUuiVE99SemfBFiF3BNh/pHjmN1El1YTV7KOpRVDZ/O6hGvy56 tWlVmQekrdcoCuX4E1Mjg81jXrLZRFNmREm+kG6PZf85QShj7lGahvImsyYp2ONYQ2s2EO AF95U0zEhedpTXObsPo2kFOey3TqbYs= 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 947431388B; Wed, 29 Nov 2023 10:22:24 +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 8CgWIOAQZ2V+BwAAD6G6ig (envelope-from ); Wed, 29 Nov 2023 10:22:24 +0000 Date: Wed, 29 Nov 2023 11:22:23 +0100 From: Michal Hocko To: "Huang, Ying" Cc: Yosry Ahmed , Minchan Kim , Chris Li , 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> <87bkbf7gz6.fsf@yhuang6-desk2.ccr.corp.intel.com> <87msuy5zuv.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: <87msuy5zuv.fsf@yhuang6-desk2.ccr.corp.intel.com> X-Rspamd-Queue-Id: DD312C000F X-Rspam-User: X-Stat-Signature: 48q89xrp3uoffk5mq5oathpca1j64atb X-Rspamd-Server: rspam03 X-HE-Tag: 1701253348-740754 X-HE-Meta: U2FsdGVkX180kZP90qEwToomwdq1qIZKTymfdhPfHLZlcTzjYeNqX5qZ4wGlrnO0RlgroysLhljrOqKP69Em2nC1t3UCy0y+iaHQW8Rtjg71s6h1xqtOHLTM0EwPEBBNlQJyeDZ/XqOOX5gJ5RLRULsCZcY3dnztI4Czg1M7+SUxtwA100qnie553kTe3FJJpWVdr9pY4FSp9c+vspl/yI2ZIhoWZV+zLmDecV/Mta3gFrvYJPkgTvFFJYsRRlnliu7kSI7zs0cDZe1Ta3Bk1+pUNjhgNnnIutxIs81coraohqZvM66+xxn7bDooHfTcjtQMPx6dyq7gt9YQxeSo94XfnsSektUBf1i+W5/P/4+SP1g2x2BO2TRCPrBacCTpYMKFtb2a7+fGA3gmVc2HIYAkSCxX8+IAKedY8ybLyc7AskAyU28WUGB9H6GqQMnXOk9zKKXb0AtmJuP90cGDDhMLyH4+oPi4lYPcPi1VJdlw7owN9bGW2aKNwrigYnrUcsSwX8ryxCX+dVBpeoZyBF8I7fbMljh7/hJnWy5LWqNSOUECEizZIGVoUbo+p0KFGdCdzhtjZ3h/Wgt9ySqWQFOJbNNFc8lLpKMChcE4Csz5jk1OpzZKYNLmgPEwi0W703G7f7JE1htuCFmYdIHHd/AcIrPrKpfUrpm0KkMgfLef3bN/mfQITVaF75Ty38BeBJU0J1WzOBokvN3OWCxbJr4UzR+H2jGQAC7kNIFcKj147oJUbkJepBRwjLYFLlSULmCK7YhhQBw2JrEvj8QVIq42v3p3idFbfiSk9on7/V9ubgmOORlWJTFpRwTjPdnUJJ3HVkV5vyw+Ez6pI3gywOi361Ip4GOb/bNXEYeNK6mdoffgP6idZkF617FBbSKbkGl1Pm8YI7fmep9iwY92BDGVtyU1h6bUM0+irJ2X2W3LLLaLArwZYfx1ohlu+8s2xQeVdZ4abCuyiXoxfKy nf7KI3IB 9NArznd+Oj5BLren+4/PlGoDv3Jo+sQAtdXawjlPz/wG2hcHRyB6p51eO+i7THWrmSTubUzEmBSXhwdLn+88cg7rukoh8SPFGgLzbCSI9Kf7dS3Swk4noZIxzTpZsQVYiNM0kPuwci6WobB+X/t7Om6K9EIx3eVg4G8T/Ue6KTYoD6t9GC8zn2k+OYlMvndIMFL3JbCe7dIOeJ+np7SbSah/r/KuLDFOQgvfvtb5VLMxr309PBYKfTrO8Kf53yTb8i3hCAS2+LVjcDQGJFh2hTgRZMFwji3g/+WaBp3TeQ4SwqzqSDQt5DwY3JdN1XcbUf2S4 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 Tue 28-11-23 11:19:20, Huang, Ying wrote: > Yosry Ahmed writes: > > > On Mon, Nov 27, 2023 at 1:32 PM Minchan Kim wrote: > >> > >> On Mon, Nov 27, 2023 at 12:22:59AM -0800, Chris Li wrote: > >> > On Mon, Nov 27, 2023 at 12:14 AM Huang, Ying wrote: > >> > > > I agree with Ying that anonymous pages typically have different page > >> > > > access patterns than file pages, so we might want to treat them > >> > > > differently to reclaim them effectively. > >> > > > One random idea: > >> > > > How about we put the anonymous page in a swap cache in a different LRU > >> > > > than the rest of the anonymous pages. Then shrinking against those > >> > > > pages in the swap cache would be more effective.Instead of having > >> > > > [anon, file] LRU, now we have [anon not in swap cache, anon in swap > >> > > > cache, file] LRU > >> > > > >> > > I don't think that it is necessary. The patch is only for a special use > >> > > case. Where the swap device is used up while some pages are in swap > >> > > cache. The patch will kill performance, but it is used to avoid OOM > >> > > only, not to improve performance. Per my understanding, we will not use > >> > > up swap device space in most cases. This may be true for ZRAM, but will > >> > > we keep pages in swap cache for long when we use ZRAM? > >> > > >> > I ask the question regarding how many pages can be freed by this patch > >> > in this email thread as well, but haven't got the answer from the > >> > author yet. That is one important aspect to evaluate how valuable is > >> > that patch. > >> > >> Exactly. Since swap cache has different life time with page cache, they > >> would be usually dropped when pages are unmapped(unless they are shared > >> with others but anon is usually exclusive private) so I wonder how much > >> memory we can save. > > > > I think the point of this patch is not saving memory, but rather > > avoiding an OOM condition that will happen if we have no swap space > > left, but some pages left in the swap cache. Of course, the OOM > > avoidance will come at the cost of extra work in reclaim to swap those > > pages out. > > > > The only case where I think this might be harmful is if there's plenty > > of pages to reclaim on the file LRU, and instead we opt to chase down > > the few swap cache pages. So perhaps we can add a check to only set > > sc->swapcache_only if the number of pages in the swap cache is more > > than the number of pages on the file LRU or similar? Just make sure we > > don't chase the swapcache pages down if there's plenty to scan on the > > file LRU? > > The swap cache pages can be divided to 3 groups. > > - group 1: pages have been written out, at the tail of inactive LRU, but > not reclaimed yet. > > - group 2: pages have been written out, but were failed to be reclaimed > (e.g., were accessed before reclaiming) > > - group 3: pages have been swapped in, but were kept in swap cache. The > pages may be in active LRU. > > The main target of the original patch should be group 1. And the pages > may be cheaper to reclaim than file pages. Thanks this is really useful summary. And it begs question. How are we telling those different types from each other? vmstat counter is certainly not sufficient and that means we might be scanning a lot without actually making any progress. And doing that repeatedly. -- Michal Hocko SUSE Labs