From: zhiguojiang <justinjiang@vivo.com>
To: Michal Hocko <mhocko@suse.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: Fri, 17 Jan 2025 12:41:40 +0800 [thread overview]
Message-ID: <a0c310ba-8a43-4f61-ba01-f0d385f1253e@vivo.com> (raw)
In-Reply-To: <Z4kZa0BLH6jexJf1@tiehlicka>
在 2025/1/16 22:36, Michal Hocko 写道:
> On Thu 16-01-25 22:22:42, Zhiguo Jiang wrote:
>> Currently, the try_to_free_mem_cgroup_pages interface releases the
>> memory occupied by the memcg, which defaults to all zones in the system.
>> However, for multi zone systems, such as when there are both movable zone
>> and normal zone, it is not possible to release memory that is only in
>> the normal zone.
>>
>> This patch is used to implement the try_to_free_mem_cgroup_pages interface
>> to support for releasing the specified zone's memory occupied by the
>> memcg in a multi zone systems, in order to optimize the memory usage of
>> multiple zones.
> Could you elaborate more on the actual usecase please? Who is going to
> control which zone to reclaim from, how and why?
Hi Michal Hocko,
Thanks for your comments.
In the memory allocation process, it can be known that the application
gfp flags determine which zones it can only alloc memory from.
__alloc_frozen_pages_noprof
--> prepare_alloc_pages
--> ac->highest_zoneidx = gfp_zone(gfp_mask);
The order of allocation from zones is as follows:
MOVABLE=>HIGHMEM=>NORMAL=>DMA32=>DMA.
For example, in a dual zone system with both movable and normal zones,
according to the GFP_ZONE_TABLE table, it can be known that which zone
can different gfp flags alloc memory from, as follows:
* GFP_ZONE_TABLE
* bit result
* =================
* 0x0 => NORMAL
* 0x1 => DMA or NORMAL
* 0x2 => HIGHMEM or NORMAL
* 0x3 => BAD (DMA+HIGHMEM)
* 0x4 => DMA32 or NORMAL
* 0x5 => BAD (DMA+DMA32)
* 0x6 => BAD (HIGHMEM+DMA32)
* 0x7 => BAD (HIGHMEM+DMA32+DMA)
* 0x8 => NORMAL (MOVABLE+0)
* 0x9 => DMA or NORMAL (MOVABLE+DMA)
* 0xa => MOVABLE (Movable is valid only if HIGHMEM is set too)
* 0xb => BAD (MOVABLE+HIGHMEM+DMA)
* 0xc => DMA32 or NORMAL (MOVABLE+DMA32)
* 0xd => BAD (MOVABLE+DMA32+DMA)
* 0xe => BAD (MOVABLE+DMA32+HIGHMEM)
* 0xf => BAD (MOVABLE+DMA32+HIGHMEM+DMA)
The gfps containing __GFP_MOVABLE | __GFP_HIGHMEM can alloc from both
the movable zone and the normal zone, while other gfp flags such as
GFP_KERNEL can only alloc from the normal zone, even if there is very
little free memory in the normal zone and a lot of memory in the movable
zone in the current system.
In response to the above situation, we need reclaim only the normal
zone's memory occupied by memcg by try_to_free_mem_cgroup_pages(), in
order to solve the issues of the gfp flags allocations and failure due
to gfp flags limited only to alloc memory from the normal zone. At this
point, if the memcg memory reclaimed by try_to_free_mem_cgroup_pages()
mainly comes from the movable zone, which cannot solve such problems.
In try_to_free_mem_cgroup_pages(), the sc.reclaim_idx will determine
which zones the memcg's memory are reclaimed from. The current
sc.reclaim_idx is fixed to MAX_NR_ZONES - 1, which means memcg is
fixed to reclaim all the zones's memory occupied by it.
Thanks
>
next prev parent reply other threads:[~2025-01-17 4:41 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 [this message]
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
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=a0c310ba-8a43-4f61-ba01-f0d385f1253e@vivo.com \
--to=justinjiang@vivo.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--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