From: Michal Hocko <mhocko@suse.com>
To: zhiguojiang <justinjiang@vivo.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>,
cgroups@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, opensource.kernel@vivo.com
Subject: Re: [PATCH] mm: memcg supports freeing the specified zone's memory
Date: Mon, 20 Jan 2025 10:40:51 +0100 [thread overview]
Message-ID: <Z44aI3c5M6Y9utuM@tiehlicka> (raw)
In-Reply-To: <b2d25ba9-8773-4e17-b5d9-2dbc90382eb5@vivo.com>
On Mon 20-01-25 09:22:47, zhiguojiang wrote:
>
>
> 在 2025/1/17 19:43, Michal Hocko 写道:
> > On Fri 17-01-25 18:25:13, zhiguojiang wrote:
> > [...]
> > > > Could you describe problem that you are trying to solve?
> > > In a dual zone system with both movable and normal zones, we encountered
> > > the problem where the GFP_KERNEL flag failed to allocate memory from the
> > > normal zone and crashed. Analyzing the logs, we found that there was
> > > very little free memory in the normal zone, but more free memory in the
> > > movable zone at this time. Therefore, we want to reclaim accurately
> > > the normal zone's memory occupied by memcg through
> > > try_to_free_mem_cgroup_pages().
> > Could you be more specific please? What was the allocation request. Has
> > the allocation or charge failed? Do you have allocation failure memory
> > info or oom killer report?
> Hi Michal Hocko,
>
> RAM12GB, Normal zone 7GB, Movable zone 5GB.
> Issue: kmalloc-order3 fails from Normal zone and triggers oom-killer. At
> this time,
> there is no order3 memory in Normal zone, but there is still a lot in
> Movable zone.
Thank you, I believe this makes the situation much more clear. It seems
that the Zone normal is too fragmented to satisfy order-3 allocation
request (the amount of free memory is above high watermark). That means
that the focus should be more on memory compaction rather than reclaim.
And more importantly at the global level rather than memcg.
Also you are running quite an old kernel which might be missing many
compaction related improvements. I would recommend re-running your
workload with the current Linus tree to see whether your problem is
still reproducible. If yes, please report along with compaction counters
(reported viac /proc/vmstat).
Good luck!
--
Michal Hocko
SUSE Labs
prev parent reply other threads:[~2025-01-20 9:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-16 14:22 Zhiguo Jiang
2025-01-16 14:36 ` Michal Hocko
2025-01-17 4:41 ` zhiguojiang
2025-01-17 9:33 ` Michal Hocko
2025-01-17 10:25 ` zhiguojiang
2025-01-17 11:43 ` Michal Hocko
2025-01-20 1:22 ` zhiguojiang
2025-01-20 9:40 ` Michal Hocko [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=Z44aI3c5M6Y9utuM@tiehlicka \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=justinjiang@vivo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=opensource.kernel@vivo.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@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