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 AA4ADC4332F for ; Mon, 6 Nov 2023 06:59:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2AE85440170; Mon, 6 Nov 2023 01:59:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 25D31440150; Mon, 6 Nov 2023 01:59:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1264A440170; Mon, 6 Nov 2023 01:59:59 -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 006EF440150 for ; Mon, 6 Nov 2023 01:59:58 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id CE0E7B50F3 for ; Mon, 6 Nov 2023 06:59:58 +0000 (UTC) X-FDA: 81426629676.29.6353125 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) by imf20.hostedemail.com (Postfix) with ESMTP id 3E41C1C0006 for ; Mon, 6 Nov 2023 06:59:55 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=SL1XE0sR; spf=pass (imf20.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.7 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699253997; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=HxQao/a5oHfhY8wpu6BRSUOvdgwN6AhROqzhmNUotRI=; b=2WE5+qgNACTGFzZrxWoJJX67OUJKWInf6ov4su3LDLMyL+2xbk3Gry3YPRpsLq0wWeiczQ rEbWhK7yKA5XCOZwNGpyzXUf5rkwXIxNVsde8DzZ80TZ/BW2uuikmy6dPLYYGIYlmnwXE+ Kr2E4ODS9hZjzSpKqOfh5lEf6zn7WaE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699253997; a=rsa-sha256; cv=none; b=6XYkWZE9uF2Gkz98J7LX12GUSRKhWknnnlooeqPeFquSTubkg02fxznx0CUhMum1ULr9+2 Sw8BfTXYyVpzmP3OPEVQAKIEke0zwai3RKXVb0FDnCMRHCwOWOumUvU+LgfixqmfItMlzy gbfMNpa9rgUvXoj6e1H9FOfjaMXNHw4= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=SL1XE0sR; spf=pass (imf20.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.7 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1699253996; x=1730789996; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=dbh2CWMpd+icdilLpDkSpVgYFt/E0AyxSgbvKFOsvd8=; b=SL1XE0sRR7xXvjF02+7r7qHRitvM7T7lG+uH9X0BVs2KWdaKuh09Q1MV iTr8IB3iXuCOzW+pT00Es8ThMQoG+qJ3+zTg3ppBdEKLZk2td7ADJUnOf q19g4KP6xBaBV5BwFo57KxE0Byv2eXXBLFs9Q7q361dj/86zhnqnBm8yZ k1I5XgsjQGaqzJS//SIV6/gmhy+U/VPtjE8dOT6riRBH25JvNkiE+u7ne 7hTNEVTkWx1/Pvgban5RJjixBUdxSs7/80R4dKGVA+bdgxIzwYG7nveUn auOmtVVjqynSn4rJf55YWnPsackfjEfqpNdoZZ0G5QuozNjfLfSVp/pdk w==; X-IronPort-AV: E=McAfee;i="6600,9927,10885"; a="10757433" X-IronPort-AV: E=Sophos;i="6.03,280,1694761200"; d="scan'208";a="10757433" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Nov 2023 22:59:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10885"; a="762236548" X-IronPort-AV: E=Sophos;i="6.03,280,1694761200"; d="scan'208";a="762236548" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Nov 2023 22:59:51 -0800 From: "Huang, Ying" To: Liu Shixin Cc: Andrew Morton , Yosry Ahmed , Sachin Sant , Michal Hocko , Johannes Weiner , Kefeng Wang , , Subject: Re: [PATCH v8] mm: vmscan: try to reclaim swapcache pages if no swap space In-Reply-To: <20231106074452.2581835-1-liushixin2@huawei.com> (Liu Shixin's message of "Mon, 6 Nov 2023 15:44:52 +0800") References: <20231106074452.2581835-1-liushixin2@huawei.com> Date: Mon, 06 Nov 2023 14:57:49 +0800 Message-ID: <87pm0nv05u.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Queue-Id: 3E41C1C0006 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: t18jh7y7bmamdkdd51qnxckonzygfgz9 X-HE-Tag: 1699253995-59182 X-HE-Meta: U2FsdGVkX19irGSZn94W6pi3HFlos87agKE0aWDHm1LcZm0pl9/XN75xmTznrkJE0j9w21T72y01dQ0BJS7iDRdfixLccOJPVXwPKgbghTA5CuQhsuhDfgdERbx84wVdyAdkwNXg/htZZC08Q47iiXlKDHR//VVy9bcx0X82tJCvf/ZHBG1ToO9IVzimeHOMe1N5FoF6M+rQOhIkZ88BcIAyG5r07L6o6SupAQa9sFXiWDbATFzf09Tir4mgKTgSrV2SCk8eIA37pvO8ooTOBH41aNKVKWiw2D90fH2DrXFgl8p5CaYwxERUEEqdzB91vMeZ1L0Ldo5dIo+bHaN6Ei7b1V2AXcJHaqfxN+qWLZdmOw0vS4ItQ7rlWU+3q4+3UUzXQoBdiGsCK4emv7ECIAlr8tGdlX4PKbxSUySqcaxSSRAb26hby+SL1wXMi0sH3FrsqziBY9ziGDH+TlDM8790je4+TNFLC2XI2vDjjVqYzVYcdewucmomL9y9fgkFOaz0Ksh3PqtMmsk8IdAI4EkHxCNn5xbFOuH1+pGAldThBy0CqQEg8F66E0WJZz9IzHjqHC+HvsmCv6yfIZOpa26CgpEMiWx/bmAZurIxlUuW1lPpxRW1mEUJYYyxhKxMsEvOQi9LBb/lsmdL4+B9yVu2xc5Tq6SMrPAlmNxZSUZzyuxtzmnrmdvHtkQk0LlcmWzeX5BDYAESyvT/8dV0YfLJZLnQ9eMIOSbnRRVhBjBauAEYsKcZ939npWmnvlj6HyxzXfc42ZmveLDZPXDfTSjMQln6UgmYLTEjJnbYDKB4Cxq2UL2Z4OiCE/kljA0+EqiOZ6bSk1zcpMwAnUnjtNJwxfoqgK4DbBFglDNzvIuacTnOnGgICTAdGj9UGoxkh+FX+ZM7ok18lLEMQC4OG6m1oZUj2BmcJuN8vrdTG6YZyBCQdpLrJUlk0kKpY/vKiy9AoZZ5tAN6/sxQqSu 3e2OUGNJ MKwkGlba1u6J0IWd1v3SvkQYu2KeXquEdmHiWlQP+ufB8JDFZFKg+aAToPjPWw78XX2KJBppp25ta7bYDmArPZHcJZKCMsf9g0u7MAqBVGdcqHlFWJRbHGbVj05S7hxvazBrL2mL5tw5BGgJeTOd5a9a0PfFCJ6XbhUo4kSNvJrhIYRWEbuXRTd/Cx1amBuUqxE2/T29qYGS3Q9Q6u2+ff1RonaQoouKnooezWkApIlh3DgSahgpHcuJ8goB3MuhyG8tKvy9NVtt6MByVjLnksyRrJ3PYebNLu00560y/F1Adwms= 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: Liu Shixin writes: > When spaces of swap devices are exhausted, only file pages can be > reclaimed. But there are still some swapcache pages in anon lru list. > This can lead to a premature out-of-memory. > > The problem is found with such step: > > Firstly, set a 9MB disk swap space, then create a cgroup with 10MB > memory limit, then runs an program to allocates about 15MB memory. > > The problem occurs occasionally, which may need about 100 times [1]. > > Fix it by checking number of swapcache pages in can_reclaim_anon_pages(). > If the number is not zero, return true and set swapcache_only to 1. > When scan anon lru list in swapcache_only mode, non-swapcache pages will > be skipped to isolate in order to accelerate reclaim efficiency. > > 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]. > > By the way, since there are enough times of memory reclaim before OOM, it > is not need to isolate too much swapcache pages in one times. > > [1]. https://lore.kernel.org/lkml/CAJD7tkZAfgncV+KbKr36=eDzMnT=9dZOT0dpMWcurHLr6Do+GA@mail.gmail.com/ > [2]. https://lore.kernel.org/linux-mm/CAJD7tkafz_2XAuqE8tGLPEcpLngewhUo=5US14PAtSM9tLBUQg@mail.gmail.com/ > > Signed-off-by: Liu Shixin > Tested-by: Yosry Ahmed > Reviewed-by: "Huang, Ying" > Reviewed-by: Yosry Ahmed > --- > v7->v8: Reset swapcache_only at the beginning of can_reclaim_anon_pages(). > v6->v7: Reset swapcache_only to zero after there are swap spaces. > v5->v6: Fix NULL pointing derefence and hung task problem reported by Sachin. > > include/linux/swap.h | 6 ++++++ > mm/memcontrol.c | 8 ++++++++ > mm/vmscan.c | 27 +++++++++++++++++++++++++++ > 3 files changed, 41 insertions(+) > > diff --git a/include/linux/swap.h b/include/linux/swap.h > index f6dd6575b905..3ba146ae7cf5 100644 > --- a/include/linux/swap.h > +++ b/include/linux/swap.h > @@ -659,6 +659,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 entry) > @@ -681,6 +682,11 @@ static inline long mem_cgroup_get_nr_swap_pages(struct 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 5b009b233ab8..29e34c06ca83 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -7584,6 +7584,14 @@ long mem_cgroup_get_nr_swap_pages(struct mem_cgroup *memcg) > return nr_swap_pages; > } > > +long mem_cgroup_get_nr_swapcache_pages(struct mem_cgroup *memcg) > +{ > + if (mem_cgroup_disabled()) > + return total_swapcache_pages(); > + > + return memcg_page_state(memcg, NR_SWAPCACHE); > +} > + > bool mem_cgroup_swap_full(struct folio *folio) > { > struct mem_cgroup *memcg; > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 6f13394b112e..5d5a169ec98c 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -137,6 +137,9 @@ struct scan_control { > /* Always discard instead of demoting to lower tier memory */ > unsigned int no_demotion:1; > > + /* Swap space is exhausted, only reclaim swapcache for anon LRU */ > + unsigned int swapcache_only:1; > + > /* Allocation order */ > s8 order; > > @@ -606,6 +609,9 @@ static inline bool can_reclaim_anon_pages(struct mem_cgroup *memcg, > int nid, > struct scan_control *sc) > { > + if (sc) > + sc->swapcache_only = 0; > + > if (memcg == NULL) { > /* > * For non-memcg reclaim, is there > @@ -613,10 +619,22 @@ static inline bool can_reclaim_anon_pages(struct mem_cgroup *memcg, > */ > if (get_nr_swap_pages() > 0) > return true; > + /* Is there any swapcache pages to reclaim? */ > + if (total_swapcache_pages() > 0) { > + if (sc) > + sc->swapcache_only = 1; > + return true; > + } > } else { > /* Is the memcg below its swap limit? */ > if (mem_cgroup_get_nr_swap_pages(memcg) > 0) > return true; > + /* Is there any swapcache pages in memcg to reclaim? */ > + if (mem_cgroup_get_nr_swapcache_pages(memcg) > 0) { > + if (sc) > + sc->swapcache_only = 1; > + return true; > + } > } I understand that this is only possible in theory. But if can_demote() == true, get_nr_swap_pages() == 0, total_swapcache_pages() > 0, we will demote only anonymous pages in swapcache. I think that this isn't reasonable. So, swapcache pages should be checked after can_demote() checking. -- Best Regards, Huang, Ying > /* > @@ -2342,6 +2360,15 @@ static unsigned long isolate_lru_folios(unsigned long nr_to_scan, > */ > scan += nr_pages; > > + /* > + * Count non-swapcache too because the swapcache pages may > + * be rare and it takes too much times here if not count > + * the non-swapcache pages. > + */ > + if (unlikely(sc->swapcache_only && !is_file_lru(lru) && > + !folio_test_swapcache(folio))) > + goto move; > + > if (!folio_test_lru(folio)) > goto move; > if (!sc->may_unmap && folio_mapped(folio))