[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a0c310ba-8a43-4f61-ba01-f0d385f1253e@vivo.com>
Date: Fri, 17 Jan 2025 12:41:40 +0800
From: zhiguojiang <justinjiang@...o.com>
To: Michal Hocko <mhocko@...e.com>
Cc: Johannes Weiner <hannes@...xchg.org>,
Roman Gushchin <roman.gushchin@...ux.dev>,
Shakeel Butt <shakeel.butt@...ux.dev>, Muchun Song <muchun.song@...ux.dev>,
Andrew Morton <akpm@...ux-foundation.org>, cgroups@...r.kernel.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org, opensource.kernel@...o.com
Subject: Re: [PATCH] mm: memcg supports freeing the specified zone's memory
在 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
>
Powered by blists - more mailing lists