From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
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 9C58DC77B75
	for <linux-mm@archiver.kernel.org>; Sat,  6 May 2023 01:22:54 +0000 (UTC)
Received: by kanga.kvack.org (Postfix)
	id D633F900004; Fri,  5 May 2023 21:22:53 -0400 (EDT)
Received: by kanga.kvack.org (Postfix, from userid 40)
	id D1235900002; Fri,  5 May 2023 21:22:53 -0400 (EDT)
X-Delivered-To: int-list-linux-mm@kvack.org
Received: by kanga.kvack.org (Postfix, from userid 63042)
	id C27FF900004; Fri,  5 May 2023 21:22:53 -0400 (EDT)
X-Delivered-To: linux-mm@kvack.org
Received: from mail3-162.sinamail.sina.com.cn (mail3-162.sinamail.sina.com.cn [202.108.3.162])
	by kanga.kvack.org (Postfix) with ESMTP id 4954C900002
	for <linux-mm@kvack.org>; Fri,  5 May 2023 21:22:53 -0400 (EDT)
X-SMAIL-HELO: localhost.localdomain
Received: from unknown (HELO localhost.localdomain)([114.249.59.75])
	by sina.com (172.16.97.27) with ESMTP
	id 6455ABE800002BE8; Sat, 6 May 2023 09:22:49 +0800 (CST)
X-Sender: hdanton@sina.com
X-Auth-ID: hdanton@sina.com
Authentication-Results: sina.com;
	 spf=none smtp.mailfrom=hdanton@sina.com;
	 dkim=none header.i=none;
	 dmarc=none action=none header.from=hdanton@sina.com
X-SMAIL-MID: 716723786939
From: Hillf Danton <hdanton@sina.com>
To: Doug Anderson <dianders@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Mel Gorman <mgorman@techsingularity.net>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>,
	linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	Matthew Wilcox <willy@infradead.org>,
	Yu Zhao <yuzhao@google.com>
Subject: Re: [PATCH v3] migrate_pages: Avoid blocking for IO in MIGRATE_SYNC_LIGHT
Date: Sat,  6 May 2023 09:22:39 +0800
Message-Id: <20230506012239.4306-1-hdanton@sina.com>
In-Reply-To: <CAD=FV=XWLswc8A1zgV20V1eboaq18i0js3d-VjNQtFeytPT1xw@mail.gmail.com>
References: <20230428135414.v3.1.Ia86ccac02a303154a0b8bc60567e7a95d34c96d3@changeid> <20230430085300.3173-1-hdanton@sina.com> <CAD=FV=WLHZfNN5cGMUEnvv17obVK-MLmWHJHx=MV55Q1YxczOA@mail.gmail.com> <20230503014500.3692-1-hdanton@sina.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Bogosity: Ham, tests=bogofilter, spamicity=0.000047, version=1.2.4
Sender: owner-linux-mm@kvack.org
Precedence: bulk
X-Loop: owner-majordomo@kvack.org
List-ID: <linux-mm.kvack.org>

On 5 May 2023 10:11:41 -0700 Douglas Anderson <dianders@chromium.org>
> What type of evidence are you looking for?

Because kswapd is responsible for maintaining watermarks, there is no
memory pressure if it decides to take a nap. Anyway defragmentation
can not make forward progress without enough free pages, see
kswapd_is_running() in should_proactive_compact_node().

> When I'm reproducing these
> problems, I'm running a test that specifically puts the system under
> memory pressure by opening up lots of tabs in the Chrome browser. When
> I start seeing these printouts, I can take a look at the system and I
> can see that it's pretty much constantly swapping in and swapping out.

Now trun to what is important. The constant swapin and swapout say more
tabs are opened than designed, and simply closing enough tabs is a better
fix, because fix like this one fails again with 20 more tabs opened for
instance.