> -----Original Message-----
> From: Michal Hocko <mhocko@xxxxxxxx>
> Sent: Tuesday, December 6, 2022 6:33 PM
> To: Shakeel Butt <shakeelb@xxxxxxxxxx>
> Cc: Li,Rongqing <lirongqing@xxxxxxxxx>; linux-mm@xxxxxxxxx;
> cgroups@xxxxxxxxxxxxxxx; hannes@xxxxxxxxxxx; roman.gushchin@xxxxxxxxx;
> songmuchun@xxxxxxxxxxxxx; akpm@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [PATCH] mm: memcontrol: speedup memory cgroup resize
>
> On Mon 05-12-22 08:32:41, Shakeel Butt wrote:
> > On Mon, Dec 5, 2022 at 3:49 AM <lirongqing@xxxxxxxxx> wrote:
> > >
> > > From: Li RongQing <lirongqing@xxxxxxxxx>
> > >
> > > when resize memory cgroup, avoid to free memory cgroup page one by
> > > one, and try to free needed number pages once
> > >
> >
> > It's not really one by one but SWAP_CLUSTER_MAX. Also can you share
> > some experiment results on how much this patch is improving setting
> > limits?
>
If try to resize a cgroup to reclaim 50 Gb memory, and this cgroup has lots of children cgroups who are reading files and alloc memory, this patch can speed 2 or more times.
> Besides a clear performance gain you should also think about a potential over
> reclaim when the limit is reduced by a lot (there might be parallel reclaimers
> competing with the limit resize).
>
to avoid over claim, how about to try to free half memory once?
@@ -3498,7 +3499,11 @@ static int mem_cgroup_resize_max(struct mem_cgroup *memcg,
continue;
}
- if (!try_to_free_mem_cgroup_pages(memcg, 1, GFP_KERNEL,
+ nr_pages = page_counter_read(counter);
+
+ nr_pages = nr_pages > (max + 1) ? (nr_pages - max) / 2 : 1;
+
+ if (!try_to_free_mem_cgroup_pages(memcg, nr_pages, GFP_KERNEL,
memsw ? 0 : MEMCG_RECLAIM_MAY_SWAP)) {
ret = -EBUSY;
break; thanks
thanks
-Li
