On Tue, Sep 28, 2021 at 12:15 AM 台运方 <yunfangtai09@xxxxxxxxx> wrote: > > Yang Shi <shy828301@xxxxxxxxx> 于2021年9月28日周二 上午1:28写道: > > IMHO I don't think this is a bug. The disparity reflects the > > difference in how the page life cycle is viewed between process and > > cgroup. The usage of process comes from the rss_counter of mm. It > > tracks the per-process mapped memory usage. So it is updated once the > > page is zapped. > > > > But from the point of cgroup, the page is charged when it is allocated > > and uncharged when it is freed. The page may be zapped by one process, > > but there might be other users pin the page to prevent it from being > > freed. The pin may be very transient or may be indefinite. THP is one > > of the pins. It is gone when the THP is split, but the split may > > happen a long time after the page is zapped due to deferred split. > Thank you for reply. I agree that it reflects the difference between > process and cgroup. The memory usage of cgroup is usually used to > indicate the memory usage of the container. It can be used to avoid > the OOM and etc. The disparity will cause that the memory usage of > containers with the same processes are randomly different (we found > more than 30GB different). It is hard to manage them. Of course, > disable THP is a way to solve it. Can it have another way to solve it > ? I don't quite get what exactly you want to manage. If you want to get rid of the disparity, I don't have good idea other than splitting THP in place instead of using deferred split. But AFAIK it is not quite feasible due to some locking problems.