On Fri 16-06-23 11:31:18, 贺中坤 wrote: > On Thu, Jun 15, 2023 at 10:21 PM Michal Hocko <mhocko@xxxxxxxx> wrote: > > > > On Thu 15-06-23 22:13:09, 贺中坤 wrote: > > > > This is not really answering my question though. memcg under hard limit > > > > is not really my concern. This is a simpler case. I am not saying it > > > > doesn't need to get addresses but it is the memcg hard limited case that > > > > is much more interested. Because your charges are going to fail very > > > > likely and that would mean that swapout would fail AFAIU. If my > > > > understanding is wrong then it would really help to describe that case > > > > much more in the changelog. > > > > > > > > > > OK, Got it. In many cases I have tested, it will not fail because we did > > > not charge the page directly，but the objects(like slab,compressed page), > > > for the zspage may be shared by any memcg. > > > > That sounds like a broken design to me. > > -- > > Michal Hocko > > SUSE Labs > > I will try more cases in different compression ratios and make sure > that swapout will not fail. I do not think different compression methods will cut it. You essentially need some form of memory reserves - in memcg world pre-charged pool of memory readily available for the swapout. Another way would be to allow the charge to bypass the limit with a guarantee that this will be a temporal breach. -- Michal Hocko SUSE Labs
