Re: [PATCH] mm/memcg: add allocstall to memory.stat

[Yafang Shao <laoar.shao@gmail.com>]

On Fri, Apr 12, 2019 at 2:34 PM Michal Hocko <mhocko@kernel.org> wrote:
>
> On Fri 12-04-19 09:32:55, Yafang Shao wrote:
> > On Thu, Apr 11, 2019 at 11:10 PM Michal Hocko <mhocko@kernel.org> wrote:
> > >
> > > On Thu 11-04-19 21:54:22, Yafang Shao wrote:
> > > > On Thu, Apr 11, 2019 at 9:39 PM Michal Hocko <mhocko@kernel.org> wrote:
> > > > >
> > > > > On Thu 11-04-19 20:41:32, Yafang Shao wrote:
> > > > > > On Thu, Apr 11, 2019 at 8:27 PM Michal Hocko <mhocko@kernel.org> 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.
> > >
> > > And that is exactly what those events aim for. They are measuring
> > > _where_ the memory pressure comes from.
> > >
> > > Can you please try to explain what do you want to achieve again?
> >
> > To know the impact of this memory pressure.
> > The current events can tell us the source of this pressure, but can't
> > tell us the impact of this pressure.
>
> Can you give me a more specific example how you are going to use this
> counter in a real life please?

When we find this counter is higher, we know that the applications in
this memcg is suffering memory pressure.
Then we can do some trace for this memcg, i.e. to trace how long the
applicatons may stall via tracepoint.
(but current tracepoints can't trace a specified cgroup only, that's
another point to be improved.)
I'm not sure whether it is a good practice, but it can help us.

Thanks
Yafang