On Thu, Apr 11, 2019 at 9:39 PM Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > On Thu 11-04-19 20:41:32, Yafang Shao wrote: > > On Thu, Apr 11, 2019 at 8:27 PM Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > > > > > On Thu 11-04-19 19:59:51, Yafang Shao wrote: > > > > The current item 'pgscan' is for pages in the memcg, > > > > which indicates how many pages owned by this memcg are scanned. > > > > While these pages may not scanned by the taskes in this memcg, even for > > > > PGSCAN_DIRECT. > > > > > > > > Sometimes we need an item to indicate whehter the tasks in this memcg > > > > under memory pressure or not. > > > > So this new item allocstall is added into memory.stat. > > > > > > We do have memcg events for that purpose and those can even tell whether > > > the pressure is a result of high or hard limit. Why is this not > > > sufficient? > > > > > > > The MEMCG_HIGH and MEMCG_LOW may not be tiggered by the tasks in this > > memcg neither. > > They all reflect the memory status of a memcg, rather than tasks > > activity in this memcg. > > I do not follow. Can you give me an example when does this matter? I For example, the tasks in this memcg may encounter direct page reclaim due to system memory pressure, meaning it is stalling in page alloc slow path. At the same time, maybe there's no memory pressure in this memcg, I mean, it could succussfully charge memcg. > thought it is more important to see that there is a reclaim activity > for a specific memcg as you account for that memcg. > If you want to see/measure a reclaim imposed latency on a task then > the counter doesn't make so much sense as you have no way to match that > to a task. We have tracepoints for that purpose. By the way, I have submitted a patch for enhancement to the memcg tracepoints serveral days ago, pls. help take a look. Thanks Yafang
