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 [thread overview]
Message-ID: <20230506012239.4306-1-hdanton@sina.com> (raw)
In-Reply-To: <CAD=FV=XWLswc8A1zgV20V1eboaq18i0js3d-VjNQtFeytPT1xw@mail.gmail.com>
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.
prev parent reply other threads:[~2023-05-06 1:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-28 20:54 Douglas Anderson
2023-04-29 2:33 ` Matthew Wilcox
2023-04-29 10:13 ` Hillf Danton
2023-05-02 21:08 ` Doug Anderson
2023-05-02 8:29 ` Mel Gorman
[not found] ` <20230430085300.3173-1-hdanton@sina.com>
2023-05-02 21:20 ` Doug Anderson
2023-05-03 1:45 ` Hillf Danton
2023-05-05 17:11 ` Doug Anderson
2023-05-06 1:22 ` Hillf Danton [this message]
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=20230506012239.4306-1-hdanton@sina.com \
--to=hdanton@sina.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=dianders@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
--cc=yuzhao@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox