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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 11, 2019 at 11:10 PM Michal Hocko <mhocko@xxxxxxxxxx> wrote:
>
> On Thu 11-04-19 21:54:22, Yafang Shao wrote:
> > 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.
>
> 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.
The tracepoints are always off until we meet some issue and then turn it on;
while the event counter is more lightweight, and with it we can know
which memcg is suffering this pressure.

Thanks
Yafang




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux