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 164E5EE4996 for ; Tue, 22 Aug 2023 16:36:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8454E280049; Tue, 22 Aug 2023 12:36:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F52B280048; Tue, 22 Aug 2023 12:36:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 670C7280049; Tue, 22 Aug 2023 12:36:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 5791B280048 for ; Tue, 22 Aug 2023 12:36:24 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 0E2E840403 for ; Tue, 22 Aug 2023 16:36:24 +0000 (UTC) X-FDA: 81152293488.22.A1A7113 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf26.hostedemail.com (Postfix) with ESMTP id 399CE14001C for ; Tue, 22 Aug 2023 16:36:22 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=gDjUEyD7; spf=pass (imf26.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692722182; a=rsa-sha256; cv=none; b=DaOJT0ml9Qmdbx01YsWLeMYyzXLbci7gNzfo2ZBQ215aIl9llCBQL3H19+eWr7Rq9tMioQ KSGF7Ghbj+AL/lsG4YiipEDLQZEIXGPPNZeMbo64KR7lt+ZzxSjmlD8pz9ZzYizB7F3Nkr p4UAz+FNMlbZNuswdgAYAi+ECOfidKQ= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=gDjUEyD7; spf=pass (imf26.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.41 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=1692722182; 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=J1Og0p3YsszYT5eyrrRdHLABJeyVk3h/09oUuO+tzhE=; b=FC2MuwX+YonGjM0DUCj5tOKdSzdSigAedw9TArgHjKvQEss54eCf7UBGcdZ4f/dHQ+4xBE SZqWGmbmGBRbGMDAc93016g3S/9Pscz+lce6S1Q5l8wxkWiAndn18hbaWGxeFZqt7HqQc7 gwnRIsrWOrvcaVUnWXFZbh5eU5/QfA0= Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-52a1ce52ef4so883091a12.2 for ; Tue, 22 Aug 2023 09:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1692722181; x=1693326981; 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=J1Og0p3YsszYT5eyrrRdHLABJeyVk3h/09oUuO+tzhE=; b=gDjUEyD73IAB7rXmTKqH6+glsZKCHbYebuG08TAomJFqxwmRCh9mwKKlMjNA+7IOQK HhueFesfKUdocFF9KJVJRMPyUYh5+s60/hD8HTL5/EayDayVWBwRX7w15bEpxAjBr1D+ RlTqPsiABd8hN+dvwvSfoI2h0YMFhNtNF2RD4k39TRNWx1WbdsQ9FYVQiKuN9xYEy0Ki OzyzDs3rl7ChWcjUEvNH23dcUPRg2tzRqIGMjnoZnOIOhhClLW/dEwZ3JT8crBXDCAEe WGwU/VxQgVxOK4zS1x8A30TV4dtbZW/lV1r49ZmXV88m9Nj/DEG2P6+6XnrufjLIz9ev hArQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692722181; x=1693326981; 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=J1Og0p3YsszYT5eyrrRdHLABJeyVk3h/09oUuO+tzhE=; b=Nj1FHdRoGkU/vkJDd+HzkwTD9K/LhQ6caQVUYCmz8+TuraxuO86I3i3DYs0KDzO0+X nkQzyvxxrkT8qwPD5yWwIDEtlNF4C+lfssfDLYHvT2uPrJUkNO0SIg9wpLS54OyImYy4 wP2PBBVUD0Ncr+xk0C/VSXXSnZo80fPF2JrPcgnk7kF9sQeXwIuQi0tMMHbJHXgxV5nB 0dBV8W53dSDDb0kp0vWT1Avh5ntUMQsnlhcpMwG0SWLUjtg+faQt9UrqXtitn97mz98Y l4CbOopm4YfUOzXYdOTsxebg+OoxGg0FdAkIy29wPef5tFtLvlhdXGslhQ6Cn7Z7w0zx u6Rw== X-Gm-Message-State: AOJu0Ywi3/PRyfn5/8nneH4xq4kOe1yG79QEkgWsJEMJ3jSqSBtMp/86 MICz5/XUHd5U9t8VQ4MQ/EAxoP2M9jJwrhpEvY0KQw== X-Google-Smtp-Source: AGHT+IF/Y7UW3BC3YfU03L2U7Xdkv8i4Mdi8P+tqfZNTm8Ng+7QrnnOIKOgtGVPZwSXzM/h/03iw9SxllfgCbjoRGas= X-Received: by 2002:a17:907:a041:b0:991:c842:2ca2 with SMTP id gz1-20020a170907a04100b00991c8422ca2mr7821581ejc.15.1692722180640; Tue, 22 Aug 2023 09:36:20 -0700 (PDT) MIME-Version: 1.0 References: <20230822024901.2412520-1-liushixin2@huawei.com> In-Reply-To: <20230822024901.2412520-1-liushixin2@huawei.com> From: Yosry Ahmed Date: Tue, 22 Aug 2023 09:35:44 -0700 Message-ID: Subject: Re: [PATCH v2] mm: vmscan: reclaim anon pages if there are swapcache pages To: Liu Shixin Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , wangkefeng.wang@huawei.com, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 399CE14001C X-Stat-Signature: 5r1zexpnpz7rsbt4o9d9zwww14ici3pg X-Rspam-User: X-HE-Tag: 1692722182-343582 X-HE-Meta: U2FsdGVkX18m4vcD73V4Q/dA7BJbzgRj+rBs4SG/b2zEbj2rs+xbAPFpB6dUzuSPf3ye3b15QCIQp43a1obeM8c6zCB+OPX6VjXq8yQLwKEL+THYcB9OpVwccm5LeUQI1y76MgNfChcRdeTwSXA4ohNqoSETSRFWdcDxy56fnDgNxWhDK7EYkZ6SfQA9/Te/4dziwMPjWNGoeaqlaMiZTq2wxCXEIH9ovtEd0FweeN1vsBTVCHNj1yBfNasLWUxOf5S6decM+MfjxU/rXRE4/3rMCj0aQyP0K6pk6G44DZbEh0G4ACENgjlcz03VhB6HyNcW5/CfbkKw73LNZ3luoPLG+/61uuQTtLHmssR3OhOkvuHiC0Lyf7AuoUUGbJ8dajtzoCydgy992FpejqjydlDw/eoEFe2faXdsUhnqK+hQrAwBHLplCoyzIoTs+G/NCFxTAu1dar/7n2tzoDjJSUgae/n6qt9JYHYVAGstlOC8JhLPKv8YjZm9DNIenWHGam3/6dNsuBfjByhkfW/LFFVGIH80GU8kQg1KVvhWh1/hDE3cZ8slbaWwtZXT52pDGOGCL4RO9dRnt6Wv3OYgSm42+ioqh/Mr7n1n/igqjjPwjfiTKHQ39Tm6JPlB/RVpq9H0kCDJY/Gz1twjWO9J1TZqDWwRWwnf1MlPca3zlaAL/rllG53xA5rvTnPvaKQ7Vu5tj32o5QI2V2kTxpj9LNeujCoY5XslfLevMGR5WQI4W1jBg1MKPoaoyl+904q9x2/p1kNyvotle3QDXZ+RdsaH1xVomsaX5W4/Mi2ajJB9643H9aHCtrpTb3kCQs7gEwGHed+Xax8CpbJF+yYeZx90rPY5BbYv7CRMGIiwN5gbvnJbcJzUNq2LByBRF4Qs+B4hjIcx60Vve9f3fAiUrbwNyi21sWdY8dylbh1mPiWGssWiU91shlr+ZA65qcEmyWoPSZMplHICrpggEgU tAfz4BFU wChUvGznyzS/SeaZwXZXnzHLtBujmDnsCVt1DO6D86TvI4Rp8GlUpFoQxRRcpnpqeXBKypMTdiQ/CuP+PyPQzYS/DGM93pkzSdHMdQj2ERUT8Rd9fXjzaWbd7ZtpilvgEhHpgJD6LxKj9zkC8+mxLagBXL62upf7/iLDGHrKIMiVIkmIfNg62rPcq6ZG7yTVVyLkuDq4dcAV+OqGpzl3j/4Mv9gMRTxb61tSLZVlI1vJK5pK6dNx6bV/Bp54hOukbGgOrnzJETouNSY2oS3eiMOMa+weW3oUZU1WA 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: On Mon, Aug 21, 2023 at 6:54=E2=80=AFPM Liu Shixin = wrote: > > When spaces of swap devices are exhausted, only file pages can be reclaim= ed. > But there are still some swapcache pages in anon lru list. This can lead > to a premature out-of-memory. > > This problem can be fixed by checking number of swapcache pages in > can_reclaim_anon_pages(). For memcg v2, there are swapcache stat that can > be used directly. For memcg v1, use total_swapcache_pages() instead, whic= h > may not accurate but can solve the problem. Interesting find. I wonder if we really don't have any handling of this situation. > > Signed-off-by: Liu Shixin > --- > include/linux/swap.h | 6 ++++++ > mm/memcontrol.c | 8 ++++++++ > mm/vmscan.c | 12 ++++++++---- > 3 files changed, 22 insertions(+), 4 deletions(-) > > diff --git a/include/linux/swap.h b/include/linux/swap.h > index 456546443f1f..0318e918bfa4 100644 > --- a/include/linux/swap.h > +++ b/include/linux/swap.h > @@ -669,6 +669,7 @@ static inline void mem_cgroup_uncharge_swap(swp_entry= _t entry, unsigned int nr_p > } > > extern long mem_cgroup_get_nr_swap_pages(struct mem_cgroup *memcg); > +extern long mem_cgroup_get_nr_swapcache_pages(struct mem_cgroup *memcg); > extern bool mem_cgroup_swap_full(struct folio *folio); > #else > static inline void mem_cgroup_swapout(struct folio *folio, swp_entry_t e= ntry) > @@ -691,6 +692,11 @@ static inline long mem_cgroup_get_nr_swap_pages(stru= ct mem_cgroup *memcg) > return get_nr_swap_pages(); > } > > +static inline long mem_cgroup_get_nr_swapcache_pages(struct mem_cgroup *= memcg) > +{ > + return total_swapcache_pages(); > +} > + > static inline bool mem_cgroup_swap_full(struct folio *folio) > { > return vm_swap_full(); > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index e8ca4bdcb03c..3e578f41023e 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -7567,6 +7567,14 @@ long mem_cgroup_get_nr_swap_pages(struct mem_cgrou= p *memcg) > return nr_swap_pages; > } > > +long mem_cgroup_get_nr_swapcache_pages(struct mem_cgroup *memcg) > +{ > + if (mem_cgroup_disabled() || do_memsw_account()) > + return total_swapcache_pages(); > + > + return memcg_page_state(memcg, NR_SWAPCACHE); > +} Is there a reason why we cannot use NR_SWAPCACHE for cgroup v1? Isn't that being maintained regardless of cgroup version? It is not exposed in cgroup v1's memory.stat, but I don't think there is a reason we can't do that -- if only to document that it is being used with cgroup v1. > + > bool mem_cgroup_swap_full(struct folio *folio) > { > struct mem_cgroup *memcg; > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 7c33c5b653ef..bcb6279cbae7 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -609,13 +609,17 @@ static inline bool can_reclaim_anon_pages(struct me= m_cgroup *memcg, > if (memcg =3D=3D NULL) { > /* > * For non-memcg reclaim, is there > - * space in any swap device? > + * space in any swap device or swapcache pages? > */ > - if (get_nr_swap_pages() > 0) > + if (get_nr_swap_pages() + total_swapcache_pages() > 0) > return true; > } else { > - /* Is the memcg below its swap limit? */ > - if (mem_cgroup_get_nr_swap_pages(memcg) > 0) > + /* > + * Is the memcg below its swap limit or is there swapcach= e > + * pages can be freed? > + */ > + if (mem_cgroup_get_nr_swap_pages(memcg) + > + mem_cgroup_get_nr_swapcache_pages(memcg) > 0) > return true; > } I wonder if it would be more efficient to set a bit in struct scan_control if we only are out of swap spaces but have swap cache pages, and only isolate anon pages that are in the swap cache, instead of isolating random anon pages. We may end up isolating pages that are not in the swap cache for a few iterations and wasting cycles. > > -- > 2.25.1 >