RE: [PATCH] mm: memcontrol: speedup memory cgroup resize

["Li,Rongqing" <lirongqing@baidu.com>]

> -----Original Message-----
> From: Michal Hocko <mhocko@suse.com>
> Sent: Tuesday, December 6, 2022 6:33 PM
> To: Shakeel Butt <shakeelb@google.com>
> Cc: Li,Rongqing <lirongqing@baidu.com>; linux-mm@kvack.org;
> cgroups@vger.kernel.org; hannes@cmpxchg.org; roman.gushchin@linux.dev;
> songmuchun@bytedance.com; akpm@linux-foundation.org
> 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@baidu.com> wrote:
> > >
> > > From: Li RongQing <lirongqing@baidu.com>
> > >
> > > 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