Received: by 2002:a05:7412:8521:b0:e2:908c:2ebd with SMTP id t33csp1865412rdf; Sun, 5 Nov 2023 18:21:14 -0800 (PST) X-Google-Smtp-Source: AGHT+IHW/yIkhvOZcyt02As5uD+itBZiWcCBHdxZLGIegzgnqSu9Lzhh1zg6SZry9WTKJqzqp8cM X-Received: by 2002:a17:902:d4d0:b0:1cc:4625:74e2 with SMTP id o16-20020a170902d4d000b001cc462574e2mr13445406plg.24.1699237274217; Sun, 05 Nov 2023 18:21:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699237274; cv=none; d=google.com; s=arc-20160816; b=BI6xGISG2qyjVxm+l9JcN5Qz9wcnHQdN6QuSYt18heE8ZcfKthkn/B1JbdBSezLKTe 4gf95hRg213O480XDg0F/3f4EcsV7Bx4Wv5R2DXJ0fob3I3Z2ivalrhYhO/JYCUMrWGB 8KtxEnNkUwA2cf7dZuMgnhUx4L8l7Ipg5ERh7QeO99ejOkAmyzdOFOdAVBuhknrFms5t URt/hag8acWcOttq+rj915MKe2jlkzSA6SGgLsuRhtvzh/3mpjKyKnpdalwph+ARSvuy Ez1aPEEnNq/JI8ju6YYhrVf4V6KnxqLIFcNCqnBLQzM0Sohx7P2HDaY165PZUfEUgCgM a7gQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:dkim-signature; bh=Z45LYs6fbv5QzVVxWJ5+1djRJnJX9qEWcovaRRJgtH0=; fh=3OLdiabcX+WJSvVq7X+i2qxcitsFbjF4m7oz/rxSejY=; b=Cpp2jtHlYI5b4yPmRQxenSG4WtiB5zXrZ0Ed6sR8enB7hxuMYTvaW5/10JCWrnFW+h 9iLeerB10D8/t3sI7ZhaTdFeJDukkK7lciBllf6vaEVHfzHjYCK0/eF99+LQWUZSNdpA AB317DzxguWId4gcE7S4teQLbNzii/zNcYr6xO0a/8nlh3IyVs2D4t0UFtOrmCHlvsTn l+dD8g84X6WQ6d8X6AJb7m0KuR0ec6D+dLtd1rLKdVxP72QTXMbwo8srW1r0yTwa/wAq 6LK9J3DXJelbDEoJ3w7r2MMyV9ezDqh0A2ChJh43+4MVynZ7EVEjXTe+gmJxRaXU6z+z ckZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=lvX1Jttf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id n10-20020a170903404a00b001c5fa6d75acsi6668820pla.494.2023.11.05.18.21.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Nov 2023 18:21:14 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=lvX1Jttf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 74B1E8075904; Sun, 5 Nov 2023 18:20:17 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229671AbjKFCUN (ORCPT + 99 others); Sun, 5 Nov 2023 21:20:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229447AbjKFCUL (ORCPT ); Sun, 5 Nov 2023 21:20:11 -0500 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E6A61C6 for ; Sun, 5 Nov 2023 18:20:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1699237208; x=1730773208; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=KZ1JE9nQ/ZPSsgmW/pCfXIcQwsbXp5MJrRE9yEZvPt4=; b=lvX1JttfCEFAB1nC7vWc4eYQ44tHpQaYYYmqXfsB+3uQZehMZ22JOzDe B3V5CwFkLCj+VYwC8EwEGDXOSfSnog4vDHDFSaxYZw89l3mBznOvCMnNy 5VwIZpTN68Vv6yNrdnLkpbW364mBwELf1DZBkd00R172re4DiWuErC//q reYTyjo8/OIRch+nhrtkc4V7/85wcnqfoSjSM/ewGyDhh2bt/zhp/sxNw KhLbcdTDWB00ezNMwxXPo+G8kF5Qa/hYAf8PuhqaAqoyZwpLGpFh+uqyk ne4XD+OEr3+EprMeZJWbm1hLbeO8qo4CkANVqplPfNHONzPOdyvxqDWIN Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10885"; a="420309791" X-IronPort-AV: E=Sophos;i="6.03,279,1694761200"; d="scan'208";a="420309791" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Nov 2023 18:20:08 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10885"; a="885759898" X-IronPort-AV: E=Sophos;i="6.03,279,1694761200"; d="scan'208";a="885759898" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Nov 2023 18:20:05 -0800 From: "Huang, Ying" To: Liu Shixin Cc: Andrew Morton , Yosry Ahmed , Sachin Sant , Michal Hocko , Johannes Weiner , Kefeng Wang , , Subject: Re: [PATCH v7] mm: vmscan: try to reclaim swapcache pages if no swap space In-Reply-To: <20231104140313.3418001-1-liushixin2@huawei.com> (Liu Shixin's message of "Sat, 4 Nov 2023 22:03:13 +0800") References: <20231104140313.3418001-1-liushixin2@huawei.com> Date: Mon, 06 Nov 2023 10:18:04 +0800 Message-ID: <87h6lzy68z.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-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Sun, 05 Nov 2023 18:20:17 -0800 (PST) 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 > --- > 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 | 36 ++++++++++++++++++++++++++++++++++-- > 3 files changed, 48 insertions(+), 2 deletions(-) > > 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..a5e04291662f 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; > > @@ -602,6 +605,12 @@ static bool can_demote(int nid, struct scan_control *sc) > return true; > } > > +static void set_swapcache_mode(struct scan_control *sc, bool swapcache_only) > +{ > + if (sc) > + sc->swapcache_only = swapcache_only; > +} > + I think that it's unnecessary to introduce a new function. I understand that you want to reduce the code duplication. We can add sc->swapcache_only = false; at the beginning of can_reclaim_anon_pages() to reduce code duplication. That can cover even more cases IIUC. > static inline bool can_reclaim_anon_pages(struct mem_cgroup *memcg, > int nid, > struct scan_control *sc) > @@ -611,12 +620,26 @@ static inline bool can_reclaim_anon_pages(struct mem_cgroup *memcg, > * For non-memcg reclaim, is there > * space in any swap device? > */ > - if (get_nr_swap_pages() > 0) > + if (get_nr_swap_pages() > 0) { > + set_swapcache_mode(sc, false); > return true; > + } > + /* Is there any swapcache pages to reclaim? */ > + if (total_swapcache_pages() > 0) { > + set_swapcache_mode(sc, true); > + return true; > + } > } else { > /* Is the memcg below its swap limit? */ > - if (mem_cgroup_get_nr_swap_pages(memcg) > 0) > + if (mem_cgroup_get_nr_swap_pages(memcg) > 0) { > + set_swapcache_mode(sc, false); > return true; > + } > + /* Is there any swapcache pages in memcg to reclaim? */ > + if (mem_cgroup_get_nr_swapcache_pages(memcg) > 0) { > + set_swapcache_mode(sc, true); > + return true; > + } > } If can_demote() returns true, we shouldn't scan swapcache only. -- Best Regards, Huang, Ying > /* > @@ -2342,6 +2365,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))