linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Roman Gushchin <guro@fb.com>
To: Muchun Song <songmuchun@bytedance.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	Vladimir Davydov <vdavydov.dev@gmail.com>,
	Shakeel Butt <shakeelb@google.com>,
	Xiongchun duan <duanxiongchun@bytedance.com>,
	"fam.zheng@bytedance.com" <fam.zheng@bytedance.com>,
	"Singh, Balbir" <bsingharora@gmail.com>,
	Yang Shi <shy828301@gmail.com>,
	Alex Shi <alex.shi@linux.alibaba.com>,
	Michal Hocko <mhocko@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH v3 00/12] Use obj_cgroup APIs to charge the LRU pages
Date: Tue, 18 May 2021 14:17:03 +0000	[thread overview]
Message-ID: <34366052-8A39-4E8E-A076-8B64AB4D015D@fb.com> (raw)
In-Reply-To: <CAMZfGtUiKcM8WmP88J3K5edwLhJhsUkAUQo6rnkqx4BBOEY2SA@mail.gmail.com>

Hi Muchun!

It looks like the writeback problem will be solved in a different way, which will not require generalization of the obj_cgroup api to the cgroup level. It’s not fully confirmed yet though. We still might wanna do this generalization lingn-term, but as now I have no objections for continuing the work on your patchset. I’m on pto this week, but will take a deeper look at your patches early next week. Sorry for the delay.

Thanks!

Sent from my iPhone

> On May 18, 2021, at 06:50, Muchun Song <songmuchun@bytedance.com> wrote:
> 
> Ping...
> 
> Hi Johannes and Roman,
> 
> Any suggestions on this patch set?
> 
> Thanks.
> 
>> On Wed, Apr 21, 2021 at 3:01 PM Muchun Song <songmuchun@bytedance.com> wrote:
>> 
>> This is v3 based on the top of the series[1] (memcontrol code cleanup and
>> simplification). Roman is working on the generalization of obj_cgroup API.
>> But before that, hope someone can review this patches for correctness.
>> 
>> Since the following patchsets applied. All the kernel memory are charged
>> with the new APIs of obj_cgroup.
>> 
>>        [v17,00/19] The new cgroup slab memory controller[2]
>>        [v5,0/7] Use obj_cgroup APIs to charge kmem pages[3]
>> 
>> But user memory allocations (LRU pages) 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.
>> 
>> We can convert LRU pages and most other raw memcg pins to the objcg direction
>> to fix this problem, and then the LRU pages will not pin the memcgs.
>> 
>> This patchset aims to make the LRU pages to drop the reference to memory
>> cgroup by using the APIs of obj_cgroup. Finally, we can see that the number
>> of the dying cgroups will not increase if we run the following test script.
>> 
>> ```bash
>> #!/bin/bash
>> 
>> cat /proc/cgroups | grep memory
>> 
>> cd /sys/fs/cgroup/memory
>> 
>> for i in range{1..500}
>> do
>>        mkdir test
>>        echo $$ > test/cgroup.procs
>>        sleep 60 &
>>        echo $$ > cgroup.procs
>>        echo `cat test/cgroup.procs` > cgroup.procs
>>        rmdir test
>> done
>> 
>> cat /proc/cgroups | grep memory
>> ```
>> 
>> Thanks.
>> 
>> [1] https://lore.kernel.org/linux-mm/20210417043538.9793-1-songmuchun@bytedance.com/
>> [2] https://lore.kernel.org/linux-mm/20200623015846.1141975-1-guro@fb.com/
>> [3] https://lore.kernel.org/linux-mm/20210319163821.20704-1-songmuchun@bytedance.com/
>> 
>> Changlogs in RFC v3:
>>  1. Drop the code cleanup and simplification patches. Gather those patches
>>     into a separate series[1].
>>  2. Rework patch #1 suggested by Johannes.
>> 
>> Changlogs in RFC v2:
>>  1. Collect Acked-by tags by Johannes. Thanks.
>>  2. Rework lruvec_holds_page_lru_lock() suggested by Johannes. Thanks.
>>  3. Fix move_pages_to_lru().
>> 
>> Muchun Song (12):
>>  mm: memcontrol: move the objcg infrastructure out of CONFIG_MEMCG_KMEM
>>  mm: memcontrol: introduce compact_lock_page_lruvec_irqsave
>>  mm: memcontrol: make lruvec lock safe when the LRU pages reparented
>>  mm: vmscan: rework move_pages_to_lru()
>>  mm: thp: introduce lock/unlock_split_queue{_irqsave}()
>>  mm: thp: make deferred split queue lock safe when the LRU pages
>>    reparented
>>  mm: memcontrol: make all the callers of page_memcg() safe
>>  mm: memcontrol: introduce memcg_reparent_ops
>>  mm: memcontrol: use obj_cgroup APIs to charge the LRU pages
>>  mm: memcontrol: rename {un}lock_page_memcg() to {un}lock_page_objcg()
>>  mm: lru: add VM_BUG_ON_PAGE to lru maintenance function
>>  mm: lru: use lruvec lock to serialize memcg changes
>> 
>> Documentation/admin-guide/cgroup-v1/memory.rst |   2 +-
>> fs/buffer.c                                    |  13 +-
>> fs/fs-writeback.c                              |  23 +-
>> fs/iomap/buffered-io.c                         |   4 +-
>> include/linux/memcontrol.h                     | 182 ++++----
>> include/linux/mm_inline.h                      |   6 +
>> mm/compaction.c                                |  36 +-
>> mm/filemap.c                                   |   2 +-
>> mm/huge_memory.c                               | 171 ++++++--
>> mm/memcontrol.c                                | 562 ++++++++++++++++++-------
>> mm/migrate.c                                   |   4 +
>> mm/page-writeback.c                            |  24 +-
>> mm/page_io.c                                   |   5 +-
>> mm/rmap.c                                      |  14 +-
>> mm/swap.c                                      |  46 +-
>> mm/vmscan.c                                    |  56 ++-
>> 16 files changed, 795 insertions(+), 355 deletions(-)
>> 
>> --
>> 2.11.0
>> 

  reply	other threads:[~2021-05-18 14:17 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-21  7:00 Muchun Song
2021-04-21  7:00 ` [RFC PATCH v3 01/12] mm: memcontrol: move the objcg infrastructure out of CONFIG_MEMCG_KMEM Muchun Song
2021-05-25 16:27   ` Roman Gushchin
2021-05-26  2:46     ` [External] " Muchun Song
2021-04-21  7:00 ` [RFC PATCH v3 02/12] mm: memcontrol: introduce compact_lock_page_lruvec_irqsave Muchun Song
2021-05-25 17:21   ` Roman Gushchin
2021-05-26  2:49     ` [External] " Muchun Song
2021-04-21  7:00 ` [RFC PATCH v3 03/12] mm: memcontrol: make lruvec lock safe when the LRU pages reparented Muchun Song
2021-05-25 17:21   ` Roman Gushchin
2021-04-21  7:00 ` [RFC PATCH v3 04/12] mm: vmscan: rework move_pages_to_lru() Muchun Song
2021-04-21  7:00 ` [RFC PATCH v3 05/12] mm: thp: introduce lock/unlock_split_queue{_irqsave}() Muchun Song
2021-04-21  7:00 ` [RFC PATCH v3 06/12] mm: thp: make deferred split queue lock safe when the LRU pages reparented Muchun Song
2021-04-21  7:00 ` [RFC PATCH v3 07/12] mm: memcontrol: make all the callers of page_memcg() safe Muchun Song
2021-04-21  7:00 ` [RFC PATCH v3 08/12] mm: memcontrol: introduce memcg_reparent_ops Muchun Song
2021-05-25 17:46   ` Roman Gushchin
2021-05-26  3:01     ` [External] " Muchun Song
2021-04-21  7:00 ` [RFC PATCH v3 09/12] mm: memcontrol: use obj_cgroup APIs to charge the LRU pages Muchun Song
2021-04-21  7:00 ` [RFC PATCH v3 10/12] mm: memcontrol: rename {un}lock_page_memcg() to {un}lock_page_objcg() Muchun Song
2021-04-21  7:00 ` [RFC PATCH v3 11/12] mm: lru: add VM_BUG_ON_PAGE to lru maintenance function Muchun Song
2021-04-21  7:00 ` [RFC PATCH v3 12/12] mm: lru: use lruvec lock to serialize memcg changes Muchun Song
2021-05-18 13:49 ` [RFC PATCH v3 00/12] Use obj_cgroup APIs to charge the LRU pages Muchun Song
2021-05-18 14:17   ` Roman Gushchin [this message]
2021-05-20  3:20     ` [External] " Muchun Song
2021-05-25 17:35       ` Roman Gushchin
2021-05-26  2:41         ` Muchun Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=34366052-8A39-4E8E-A076-8B64AB4D015D@fb.com \
    --to=guro@fb.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.shi@linux.alibaba.com \
    --cc=bsingharora@gmail.com \
    --cc=duanxiongchun@bytedance.com \
    --cc=fam.zheng@bytedance.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=shakeelb@google.com \
    --cc=shy828301@gmail.com \
    --cc=songmuchun@bytedance.com \
    --cc=vdavydov.dev@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox