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 X-Spam-Level: X-Spam-Status: No, score=-16.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73D27C433ED for ; Fri, 16 Apr 2021 02:29:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DEAF1610FA for ; Fri, 16 Apr 2021 02:29:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DEAF1610FA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6143C6B0036; Thu, 15 Apr 2021 22:29:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C5276B006C; Thu, 15 Apr 2021 22:29:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 465456B0070; Thu, 15 Apr 2021 22:29:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0249.hostedemail.com [216.40.44.249]) by kanga.kvack.org (Postfix) with ESMTP id 2B03B6B0036 for ; Thu, 15 Apr 2021 22:29:48 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id DBBBA1807735A for ; Fri, 16 Apr 2021 02:29:47 +0000 (UTC) X-FDA: 78036649614.29.EA60016 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf18.hostedemail.com (Postfix) with ESMTP id 23E1E2000255 for ; Fri, 16 Apr 2021 02:29:45 +0000 (UTC) IronPort-SDR: JmHVbkeAJBrm34HJbt6mMEbVcZbQwYXnfzriSgdHGn0xIMQCJRngbDN9trvIoHFfoqmNkZ4h+C ipFiOKPOT5Rg== X-IronPort-AV: E=McAfee;i="6200,9189,9955"; a="215500869" X-IronPort-AV: E=Sophos;i="5.82,226,1613462400"; d="scan'208";a="215500869" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2021 19:29:43 -0700 IronPort-SDR: SngLhycm5K800PlphSrnzdMrT0sZYjcs3qa6a62EmAN0URS/tgUqhK/o7RbEFfQvRHlLmA8Huk qMrWdxgZwlpg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,226,1613462400"; d="scan'208";a="601326807" Received: from intel10-debian.sh.intel.com ([10.239.53.15]) by orsmga005.jf.intel.com with ESMTP; 15 Apr 2021 19:29:41 -0700 From: zhengjun.xing@linux.intel.com To: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: ying.huang@intel.com, tim.c.chen@linux.intel.com, zhengjun.xing@linux.intel.com Subject: [RFC] mm/vmscan.c: avoid possible long latency caused by too_many_isolated() Date: Fri, 16 Apr 2021 02:35:36 +0000 Message-Id: <20210416023536.168632-1-zhengjun.xing@linux.intel.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 23E1E2000255 X-Stat-Signature: groidw4suh3hhndofdfxx3pee5zwn39e Received-SPF: none (linux.intel.com>: No applicable sender policy available) receiver=imf18; identity=mailfrom; envelope-from=""; helo=mga01.intel.com; client-ip=192.55.52.88 X-HE-DKIM-Result: none/none X-HE-Tag: 1618540185-566312 Content-Transfer-Encoding: quoted-printable 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: From: Zhengjun Xing In the system with very few file pages, it is easy to reproduce "nr_isolated_file > nr_inactive_file", then too_many_isolated return tru= e, shrink_inactive_list enter "msleep(100)", the long latency will happen. The test case to reproduce it is very simple, allocate a lot of huge page= s (near the DRAM size), then do free, repeat the same operation many times. There is a 3/10 rate to reproduce the issue. In the test, sc-> gfp_mask is 0x342cca ("_GFP_IO" and "__GFP_FS" is masked),it is more easy to enter =E2=80=9Cinactive >>=3D3=E2=80=9D, then =E2=80=9Cisolated > inactive=E2=80= =9D will easy to be true. So I have a proposal to set a threshold number for the total file pages to ignore the system with very few file pages, and then bypass the 100ms sleep. It is hard to set a perfect number for the threshold, so I just give an example of "256" for it, need more inputs for it. Signed-off-by: Zhengjun Xing --- mm/vmscan.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 562e87cbd7a1..a1926463455c 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -168,6 +168,7 @@ struct scan_control { * From 0 .. 200. Higher means more swappy. */ int vm_swappiness =3D 60; +int lru_list_threshold =3D SWAP_CLUSTER_MAX << 3; =20 static void set_task_reclaim_state(struct task_struct *task, struct reclaim_state *rs) @@ -1785,7 +1786,7 @@ int isolate_lru_page(struct page *page) static int too_many_isolated(struct pglist_data *pgdat, int file, struct scan_control *sc) { - unsigned long inactive, isolated; + unsigned long inactive, isolated, active, nr_lru_pages; =20 if (current_is_kswapd()) return 0; @@ -1796,11 +1797,13 @@ static int too_many_isolated(struct pglist_data *= pgdat, int file, if (file) { inactive =3D node_page_state(pgdat, NR_INACTIVE_FILE); isolated =3D node_page_state(pgdat, NR_ISOLATED_FILE); + active =3D node_page_state(pgdat, NR_ACTIVE_FILE); } else { inactive =3D node_page_state(pgdat, NR_INACTIVE_ANON); isolated =3D node_page_state(pgdat, NR_ISOLATED_ANON); + active =3D node_page_state(pgdat, NR_ACTIVE_ANON); } - + nr_lru_pages =3D inactive + active; /* * GFP_NOIO/GFP_NOFS callers are allowed to isolate more pages, so they * won't get blocked by normal direct-reclaimers, forming a circular @@ -1809,6 +1812,10 @@ static int too_many_isolated(struct pglist_data *p= gdat, int file, if ((sc->gfp_mask & (__GFP_IO | __GFP_FS)) =3D=3D (__GFP_IO | __GFP_FS)= ) inactive >>=3D 3; =20 + if (isolated > inactive) + if (nr_lru_pages < lru_list_threshold) + return 0; + return isolated > inactive; } =20 --=20 2.17.1