All of lore.kernel.org
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <20210416023536.168632-1-zhengjun.xing@linux.intel.com> (raw)

From: Zhengjun Xing <zhengjun.xing@linux.intel.com>

In the system with very few file pages, it is easy to reproduce
"nr_isolated_file > nr_inactive_file",  then too_many_isolated return true,
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 pages
(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
“inactive >>=3”, then “isolated > inactive” 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 <zhengjun.xing@linux.intel.com>
---
 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 = 60;
+int lru_list_threshold = SWAP_CLUSTER_MAX << 3;
 
 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;
 
 	if (current_is_kswapd())
 		return 0;
@@ -1796,11 +1797,13 @@ static int too_many_isolated(struct pglist_data *pgdat, int file,
 	if (file) {
 		inactive = node_page_state(pgdat, NR_INACTIVE_FILE);
 		isolated = node_page_state(pgdat, NR_ISOLATED_FILE);
+		active = node_page_state(pgdat, NR_ACTIVE_FILE);
 	} else {
 		inactive = node_page_state(pgdat, NR_INACTIVE_ANON);
 		isolated = node_page_state(pgdat, NR_ISOLATED_ANON);
+		active = node_page_state(pgdat, NR_ACTIVE_ANON);
 	}
-
+	nr_lru_pages = 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 *pgdat, int file,
 	if ((sc->gfp_mask & (__GFP_IO | __GFP_FS)) == (__GFP_IO | __GFP_FS))
 		inactive >>= 3;
 
+	if (isolated > inactive)
+		if (nr_lru_pages < lru_list_threshold)
+			return 0;
+
 	return isolated > inactive;
 }
 
-- 
2.17.1


             reply	other threads:[~2021-04-16  2:29 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-16  2:35 zhengjun.xing [this message]
2021-04-22  8:36 ` [RFC] mm/vmscan.c: avoid possible long latency caused by too_many_isolated() Xing Zhengjun
2021-04-22 10:23   ` Hillf Danton
2021-04-23  6:55     ` Xing Zhengjun
2021-04-30  5:33     ` Xing Zhengjun
2021-04-30  6:43       ` Hillf Danton
2021-05-10  8:03         ` Xing Zhengjun
2021-05-10  9:46           ` Hillf Danton
2021-04-22 17:13   ` Yu Zhao
2021-04-22 18:51     ` Shakeel Butt
2021-04-22 18:51       ` Shakeel Butt
2021-04-22 20:15       ` Yu Zhao
2021-04-22 20:15         ` Yu Zhao
2021-04-22 20:17     ` Tim Chen
2021-04-22 20:30       ` Yu Zhao
2021-04-22 20:30         ` Yu Zhao
2021-04-22 20:38         ` Tim Chen
2021-04-22 20:57           ` Yu Zhao
2021-04-22 20:57             ` Yu Zhao
2021-04-22 21:02             ` Tim Chen
2021-04-23  6:57     ` Xing Zhengjun
2021-04-23 20:23       ` Yu Zhao
2021-04-25  0:48         ` Huang, Ying
2021-04-25  0:48           ` Huang, Ying
2021-04-27 21:53           ` Yu Zhao
2021-04-27 21:53             ` Yu Zhao
2021-04-30  5:57         ` Xing Zhengjun
2021-04-30  6:24           ` Yu Zhao
2021-04-30  6:24             ` Yu Zhao
2021-04-28 11:55     ` Michal Hocko
2021-04-28 15:05       ` Yu Zhao
2021-04-28 15:05         ` Yu Zhao
2021-04-29 10:00         ` Michal Hocko
2021-04-30  8:34           ` Yu Zhao
2021-04-30  8:34             ` Yu Zhao
2021-04-30  9:17             ` Michal Hocko
2021-04-30 17:04               ` Yu Zhao
2021-04-30 17:04                 ` Yu Zhao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210416023536.168632-1-zhengjun.xing@linux.intel.com \
    --to=zhengjun.xing@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tim.c.chen@linux.intel.com \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.