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 EA1F2C4167B for ; Tue, 28 Nov 2023 03:28:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 82AB46B0298; Mon, 27 Nov 2023 22:28:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DB3C6B02F0; Mon, 27 Nov 2023 22:28:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C9E06B02F2; Mon, 27 Nov 2023 22:28:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 5CFDF6B0298 for ; Mon, 27 Nov 2023 22:28:18 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 30E4C140189 for ; Tue, 28 Nov 2023 03:28:18 +0000 (UTC) X-FDA: 81505929876.03.A44E34F Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) by imf28.hostedemail.com (Postfix) with ESMTP id 5E108C0015 for ; Tue, 28 Nov 2023 03:28:16 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="xARZ/rSq"; spf=pass (imf28.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.53 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701142096; 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=52k2p5CyGPUAHKSXeNr7BKmEfDoFNmiiCRt1xrKRz/g=; b=cGOCIqhPEA+EHWFwvZRHIJ5Qr+kdB4lNa0vQytK++FxabE+hPAV8rx4tohoGKcLcLx51Ij hql+eQdIN/Pw6l26CyCHqMIxjYBXU7AKN42NUQBeJ756szcD/0fEJ2tP3qVagqwMeNNpn9 F8uWdKFFbxfVJFh/7GCY/kMuFL7YGNc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701142096; a=rsa-sha256; cv=none; b=Q3oFa5e50HHhv0aaHcK6hd948n2dGkHCdtqcKZvFcKfOkcdiOP80t3kgBLtCsUwbmJNT6O YIbXl1S0i1sSdWkpcNScdRyFTR6DF7yyPlnA8/R9UNzXXC864G/dieqAaWHquZNwmpdW2S cSD1R+se/3LFdlzNbKcNAr8fqK4gJr0= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="xARZ/rSq"; spf=pass (imf28.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.53 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-a03a900956dso941732666b.1 for ; Mon, 27 Nov 2023 19:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1701142095; x=1701746895; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=52k2p5CyGPUAHKSXeNr7BKmEfDoFNmiiCRt1xrKRz/g=; b=xARZ/rSqzimJwkQm5xmqUWqQc9c7CE/zGG9uTU3l9texsgfhlZf3LUYpZy2Y6NrX1U haWV1S25x51szuP76rsK32w7ASvVl4SBLm4PiETrr55GnUI1EXbG5S20oZ8pMR7Vtb3i wX3bGdwhDygKm+4aAGd0F3lnbr0ygP8EF7LAb4I3eB5KMOWE5NvJ8fTe6X4oCzrxjpXv P/zXlyjBcA7U/pw5+Mx/XnlfafcEOY4HtKOR2gyx9+E5clCT0G2QI4MyYNHP7VtZabDu FLjgDHgvzXIrT8+IlP6SD4pqNyBMW09uZYPDQ4sWtMEmv2fbmYIEj+cmlxy8/z74uKOf 0xLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701142095; x=1701746895; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=52k2p5CyGPUAHKSXeNr7BKmEfDoFNmiiCRt1xrKRz/g=; b=fhwj76/U9W4lZUyPMSnSLyfjqDAuvAbIpDijPnNR83vFPTi+M83bwCJmtIffVm4aHA mkyn+9A/VkZR5lGqxEvG5V2av1sBNDl0EhdK3w/GeP+dWGfPiYnt/j9DxWCDHf0LHJ3t FBbslMF+rBfh8cV/USddRTpjnWHLLhgGaZDfqQkzPUlqBQCon3vn1gpuMQwkmhzpetSs vYjP87ug4y7RY5AF0p3DCoicJPtZS8V3c9Byyny6XOyOKxnFD6jZUJynftSp7XGaCQiD qvnASQ63S345umcKHb/gOHxgtGfPUXMRdD6qbiGnW6R8bKPU4EGlCSJUPShsDZGHtklg UQ+g== X-Gm-Message-State: AOJu0YxOtDjsUYuSX0AThkeyjC1UiIGQ4WVGuAYlOKTiO7r9RRwcHyBT csDQWhPTHRFIBzZvmb1VROOT1ySkh83AozM1vPMH4A== X-Google-Smtp-Source: AGHT+IEx8LNvwobnDx8T7P4u06cc4stnXOlF9kWWIeNLvdVuv2+mne0/S4GlmVWguwn8jwd+aU1VZ9grdt9uhMK+RRo= X-Received: by 2002:a17:906:2bd1:b0:9e8:2441:5cd4 with SMTP id n17-20020a1709062bd100b009e824415cd4mr10023918ejg.17.1701142094665; Mon, 27 Nov 2023 19:28:14 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <87msuy5zuv.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Yosry Ahmed Date: Mon, 27 Nov 2023 19:27:36 -0800 Message-ID: Subject: Re: [PATCH v10] mm: vmscan: try to reclaim swapcache pages if no swap space To: "Huang, Ying" Cc: Minchan Kim , Chris Li , Michal Hocko , Liu Shixin , Yu Zhao , Andrew Morton , Sachin Sant , Johannes Weiner , Kefeng Wang , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 5E108C0015 X-Rspam-User: X-Stat-Signature: trps8wh83yz514kdh4dukfgk948dbam6 X-Rspamd-Server: rspam03 X-HE-Tag: 1701142096-851427 X-HE-Meta: U2FsdGVkX18TIuL6e0lJuEWTwao9PbUGddf5IBrDNyM4T7T1WxAKsipT7pstULfnDvs1FgMPF2JrYh8Olajd2sZszQF4vp9py6bJlwg8+tYoFUDlsTTDIxr7bCRaySlEQedCLB+0tcUYI/CZToMX44gPvRkCx0yct0cuXVsZFUXx69fg84C9ZmErycxoJd1VUwPkQ1d5XxoEI9LM5XkFIpv2IDPXs009U0BEB7tPlrg8RsEnDmllD728AxfsHw8g9Hy5DdYGkScqkDPJ7lQekPybuvh3ecpRBlrzzvnb1HRuoZEMUnUm+fC8NkAkhAFUhnXsrY9I+j1t8dUCCC6n1wJIWDN3viRpVSBLCOJPip1whxbHmFNqK2deiIjanGBg76HYH3S+Gu3xf/DNPT9/hPhVUxpExdlEQugwqrrZ6BinbwHVqtvv5UV5TLarT2ERfd0H+zQ6xlm/t87vqbNhwheYmgzzeA7jHWvm7sc8ICT8kX1M7I6Cg74RmozueGxaayH+bnPJwMajz4GwYE7SRwgIOL3rxKj+CsDrX2N0nigd5XMd3qdDilxLDpSe1Rfy09ZR5IOe3hYFAR4xrn3G4+1YxsrIPrhsZC+A8zmtLu/t2z6eKhuBLJTqvJBZ4hnYTaiyq4reqLbYAceiX9mG+/bz3IbrRjk4tLxRVu/J0SupfxTZKDl4UlLEASEPkuBDAd9bOdIpZzRdbAai4yN6ShDbQOyuopSB3njFFCX5wRrLdjDEdplE7zl7qgUcHTq6uCp5Nfu3kofEyjA/m7ixul8u98Wp3CALrKMjhAKvPuuVzVU0dQpuMjqAs1OxzK3mrDg9FdclDtb5AekZvoPHAODuuIfHGkeOh3OCarCtE0BXyauMTKChRf9u0aQSmO5y1NW3QDrX9lWvtmgmaj4bJsSvCJ3OtGb/gJa/KFqMOjlffOl2ZGAJb/ONaCcBcYtTF/Sjz4RKBDhJAdBwJsW tRCJ2Cew nuzkUqjcgobtgvOifW99yBxDWTSFHgziJzb7sdEZnEHSzRpGSkWaHX9kmwCMY20gRcg6O9HLndTANsP7MmPKDRD8irPJqoB6R+lC4UP9kIv1GfT51/NdQ4Hvpy9Iz5r/VzSAqKjr3R1w0qnWs0HmoRhSx9Ju3KnGWejPcK8FgWs5ybCv578pfciqUzBtg+o2IZelmzSihkbLNFqceb2Kr4nucE5oLl4Cew+ZIqRyx74BIVNRWGqFRuNjPWIDeljP7SEh/loq7PCk9H/sdm17c9Hzw69hLusw8yndHDAj5EFwi6Py2cZdFq37u8bpp+Dfcw2DLpBQ/Kk383MI= 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 Mon, Nov 27, 2023 at 7:21=E2=80=AFPM Huang, Ying = wrote: > > Yosry Ahmed writes: > > > On Mon, Nov 27, 2023 at 1:32=E2=80=AFPM Minchan Kim wrote: > >> > >> On Mon, Nov 27, 2023 at 12:22:59AM -0800, Chris Li wrote: > >> > On Mon, Nov 27, 2023 at 12:14=E2=80=AFAM 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 differe= nt LRU > >> > > > than the rest of the anonymous pages. Then shrinking against tho= se > >> > > > pages in the swap cache would be more effective.Instead of havin= g > >> > > > [anon, file] LRU, now we have [anon not in swap cache, anon in s= wap > >> > > > cache, file] LRU > >> > > > >> > > I don't think that it is necessary. The patch is only for a speci= al use > >> > > case. Where the swap device is used up while some pages are in sw= ap > >> > > cache. The patch will kill performance, but it is used to avoid O= OM > >> > > only, not to improve performance. Per my understanding, we will n= ot use > >> > > up swap device space in most cases. This may be true for ZRAM, bu= t 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 pat= ch > >> > 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, the= y > >> would be usually dropped when pages are unmapped(unless they are share= d > >> with others but anon is usually exclusive private) so I wonder how muc= h > >> 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. > > Group 2 are hard to be reclaimed if swap_count() isn't 0. > > Group 3 should be reclaimed in theory, but the overhead may be high. > And we may need to reclaim the swap entries instead of pages if the pages > are hot. But we can start to reclaim the swap entries before the swap > space is run out. > > So, if we can count group 1, we may use that as indicator to scan anon > pages. And we may add code to reclaim group 3 earlier. > My point was not that reclaiming the pages in the swap cache is more expensive that reclaiming the pages in the file LRU. In a lot of cases, as you point out, the pages in the swap cache can just be dropped, so they may be as cheap or cheaper to reclaim than the pages in the file LRU. My point was that scanning the anon LRU when swap space is exhausted to get to the pages in the swap cache may be much more expensive, because there may be a lot of pages on the anon LRU that are not in the swap cache, and hence are not reclaimable, unlike pages in the file LRU, which should mostly be reclaimable. So what I am saying is that maybe we should not do the effort of scanning the anon LRU in the swapcache_only case unless there aren't a lot of pages to reclaim on the file LRU (relatively). For example, if we have a 100 pages in the swap cache out of 10000 pages in the anon LRU, and there are 10000 pages in the file LRU, it's probably not worth scanning the anon LRU.