From: Ruifeng Su <suruifeng1@huawei.com>
To: <akpm@linux-foundation.org>
Cc: <linux-mm@kvack.org>, <cgroups@vger.kernel.org>,
<mhocko@kernel.org>, <roman.gushchin@linux.dev>,
<hannes@cmpxchg.org>, <linmiaohe@huawei.com>,
<suruifeng1@huawei.com>
Subject: [PATCH] mm, memcg: avoid recycling when there is no more recyclable memory
Date: Fri, 27 Oct 2023 17:30:04 +0800 [thread overview]
Message-ID: <20231027093004.681270-1-suruifeng1@huawei.com> (raw)
When the number of alloc anonymous pages exceeds the memory.high,
exc_page_fault successfully alloc code pages,
and is released by mem_cgroup_handle_over_high before return to user mode.
As a result, the program is trapped in a loop to exc page fault and reclaim
pages.
Here is an example of test code(do_alloc_memory is static compilation):
Execution Procedure:
mkdir -p /sys/fs/cgroup/memory/memcg_high_A
echo 50M > /sys/fs/cgroup/memory/memcg_high_A/memory.high
cgexec -g memory:memcg_high_A ./common/do_alloc_memory anon 100M &
Phenomenon:
[root@localhost memcg_high_A]# cat memory.usage_in_bytes
53903360
The test result shows that the program frequently sync iCache & dcache.
As a result,
the number of anon pages requested by the program cannot increase.
This patch changes the behavior of retry recycling.
As long as the number of successfully reclaimed pages is
less than the target number of reclaimed pages,
memory reclamation exits,
indicating that there is no more memory to reclaim directly.
Signed-off-by: Ruifeng Su <suruifeng1@huawei.com>
---
mm/memcontrol.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 5b009b233ab8..e6b5d2ddb4d2 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2561,7 +2561,6 @@ void mem_cgroup_handle_over_high(gfp_t gfp_mask)
unsigned long pflags;
unsigned long nr_reclaimed;
unsigned int nr_pages = current->memcg_nr_pages_over_high;
- int nr_retries = MAX_RECLAIM_RETRIES;
struct mem_cgroup *memcg;
bool in_retry = false;
@@ -2616,7 +2615,7 @@ void mem_cgroup_handle_over_high(gfp_t gfp_mask)
* memory.high, we want to encourage that rather than doing allocator
* throttling.
*/
- if (nr_reclaimed || nr_retries--) {
+ if (nr_reclaimed >= (in_retry ? SWAP_CLUSTER_MAX : nr_pages)) {
in_retry = true;
goto retry_reclaim;
}
--
2.33.0
next reply other threads:[~2023-10-27 1:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-27 9:30 Ruifeng Su [this message]
2023-11-01 16:16 ` Michal Koutný
-- strict thread matches above, loose matches on Subject: below --
2023-10-13 15:40 Ruifeng Su
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=20231027093004.681270-1-suruifeng1@huawei.com \
--to=suruifeng1@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linmiaohe@huawei.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=roman.gushchin@linux.dev \
/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