On Wed 07-12-22 02:31:13, Li,Rongqing wrote: > > > > -----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. Do you have any more specific numbers including a perf profile to see where the additional time is spent? I find 2 times speed up rather hard to believe. The memory reclaim itself should be more CPU heavy than additional function calls doing the same in batches. Also is this an example of a realistic usecase? > > 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? We should really focus on why would a larger batch result in a noticeably better performance. -- Michal Hocko SUSE Labs
