[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALvZod5sEcsu9AHAzdkJyjxm4ws_aKXyyer99+f2rs-OnOQAMg@mail.gmail.com>
Date: Fri, 12 Mar 2021 14:42:45 -0800
From: Shakeel Butt <shakeelb@...gle.com>
To: Johannes Weiner <hannes@...xchg.org>
Cc: Muchun Song <songmuchun@...edance.com>,
Roman Gushchin <guro@...com>, Michal Hocko <mhocko@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Vladimir Davydov <vdavydov.dev@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Linux Memory Management List <linux-mm@...ck.org>,
Xiongchun duan <duanxiongchun@...edance.com>
Subject: Re: [External] Re: [PATCH v3 2/4] mm: memcontrol: make
page_memcg{_rcu} only applicable for non-kmem page
Hi Johannes,
On Fri, Mar 12, 2021 at 11:23 AM Johannes Weiner <hannes@...xchg.org> wrote:
>
[...]
>
> Longer term we most likely need it there anyway. The issue you are
> describing in the cover letter - allocations pinning memcgs for a long
> time - it exists at a larger scale and is causing recurring problems
> in the real world: page cache doesn't get reclaimed for a long time,
> or is used by the second, third, fourth, ... instance of the same job
> that was restarted into a new cgroup every time. Unreclaimable dying
> cgroups pile up, waste memory, and make page reclaim very inefficient.
>
For the scenario described above, do we really want to reparent the
page cache pages? Shouldn't we recharge the pages to the second,
third, fourth and so on, memcgs? My concern is that we will see a big
chunk of page cache pages charged to root and will only get reclaimed
on global pressure.
Powered by blists - more mailing lists