From patchwork Sat Aug 14 05:25:07 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Muchun Song X-Patchwork-Id: 12436487 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1CA92C4320A for ; Sat, 14 Aug 2021 05:25:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8C8AD61028 for ; Sat, 14 Aug 2021 05:25:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8C8AD61028 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=bytedance.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id DC2BD8D0001; Sat, 14 Aug 2021 01:25:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D726B6B0071; Sat, 14 Aug 2021 01:25:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C60F78D0001; Sat, 14 Aug 2021 01:25:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0042.hostedemail.com [216.40.44.42]) by kanga.kvack.org (Postfix) with ESMTP id A9B976B006C for ; Sat, 14 Aug 2021 01:25:36 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 3ADCA1CB3A for ; Sat, 14 Aug 2021 05:25:36 +0000 (UTC) X-FDA: 78472548672.10.1D0DB1C Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by imf20.hostedemail.com (Postfix) with ESMTP id 631C6D0013A8 for ; Sat, 14 Aug 2021 05:25:35 +0000 (UTC) Received: by mail-pj1-f47.google.com with SMTP id w13-20020a17090aea0db029017897a5f7bcso19041488pjy.5 for ; Fri, 13 Aug 2021 22:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=0WN+1Ca2oONIC6+RCCmzf4jTeBHsA3MzR6howz8AK0E=; b=0wRQI98ijU1uWeXer/aZUSSs6aAJexilg4qccmUj5oivNSXXtzb2HYvzIH5Z85F77c FdNI+Pe1cC4fraSsnNrK+Zzg7vVu0Iu8iPMtsg+J62sXHE6uc29KfCHq00mIuBch6Oee wp1jH2MyqKmA4JBllN3IJnxmsWDlhygtcD5+h3gBvPZMiIvvF3ZtbM5nn6rQNT6a6v5d QbEnZ4hWFC8HD9Qy58Okq+qk/zFq4cHXkqNjCE1TdnwMmDWekiCx3AxgICLwUtgQWDGv CdnryurMBr3+mrjSd4VnEF0HtvMDTMLvz6awp6Ls8pOmbLjCQ9u99IGYUyHHg9brKgp5 jMZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=0WN+1Ca2oONIC6+RCCmzf4jTeBHsA3MzR6howz8AK0E=; b=TNJWIVsbvQP5jDKjQZeSiotm8sIHMuNQLVlTnjRC/y3/kQrFvHpNlzLjKBz9smZ0EB NAudFx8Xrjv4ARY/uAWitKKcyPi2MJBz0rxVZCacSW1d1Zu8OauxWjD8wwvm4te0VzAK enwnfrjvILyBgju7shIFd9VxovrK4z+UOPFFd6qZ6HN0o+c/WD21YgXFW+yuwbjy64DR kLA6diUqZmOf2ys08cUsqbqDZNT9ofWlM4Dnu1h3v0lsr49THyR3XJAM6mV1+Vvzsv7v RN39r/mbewUtdn/D5tPHDkub08/Ta98eWquOWNPnD1x6ojciC2LVhbrWTOtvHapvldEs qVhA== X-Gm-Message-State: AOAM530ikPmFOeGyrOeZxPuRI9NReS/nyPu5VyHn+KQw4Smj32BDXgiF za0bpYBej7YgqlNDC5IWzvmbWA== X-Google-Smtp-Source: ABdhPJyenO8qMymW+D0aWaQc3Rw5rx8DJmj5KXhE6IQvnbKClwjtWQR1yFiP8f1RNG96dbcnJdoBkQ== X-Received: by 2002:a62:be04:0:b029:3e0:3fca:2a8f with SMTP id l4-20020a62be040000b02903e03fca2a8fmr5657896pff.12.1628918734128; Fri, 13 Aug 2021 22:25:34 -0700 (PDT) Received: from localhost.localdomain ([139.177.225.237]) by smtp.gmail.com with ESMTPSA id s5sm4783133pgp.81.2021.08.13.22.25.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Aug 2021 22:25:33 -0700 (PDT) From: Muchun Song To: guro@fb.com, hannes@cmpxchg.org, mhocko@kernel.org, akpm@linux-foundation.org, shakeelb@google.com, vdavydov.dev@gmail.com Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, duanxiongchun@bytedance.com, fam.zheng@bytedance.com, bsingharora@gmail.com, shy828301@gmail.com, alexs@kernel.org, smuchun@gmail.com, zhengqi.arch@bytedance.com, Muchun Song Subject: [PATCH v1 00/12] Use obj_cgroup APIs to charge the LRU pages Date: Sat, 14 Aug 2021 13:25:07 +0800 Message-Id: <20210814052519.86679-1-songmuchun@bytedance.com> X-Mailer: git-send-email 2.21.0 (Apple Git-122) MIME-Version: 1.0 X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 631C6D0013A8 X-Stat-Signature: ayk841d75ds489o575fuzcci4sjfnkhm Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=bytedance-com.20150623.gappssmtp.com header.s=20150623 header.b=0wRQI98i; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf20.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.216.47 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com X-HE-Tag: 1628918735-666659 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi, This version is basded on the next-20210811 and drops RFC tag from the last version. Comments and reviews are welcome. Thanks. 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[1] [v5,0/7] Use obj_cgroup APIs to charge kmem pages[2] 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/20200623015846.1141975-1-guro@fb.com/ [2] https://lore.kernel.org/linux-mm/20210319163821.20704-1-songmuchun@bytedance.com/ Changlogs in v1: 1. Drop RFC tag. 2. Rebase to linux next-20210811. Changlogs in RFC v4: 1. Collect Acked-by from Roman. 2. Rebase to linux next-20210525. 3. Rename obj_cgroup_release_uncharge() to obj_cgroup_release_kmem(). 4. Change the patch 1 title to "prepare objcg API for non-kmem usage". 5. Convert reparent_ops_head to an array in patch 8. Thanks for Roman's review and suggestions. 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: prepare objcg API for non-kmem usage mm: memcontrol: introduce compact_folio_lruvec_lock_irqsave mm: memcontrol: make lruvec lock safe when LRU pages are reparented mm: vmscan: rework move_pages_to_lru() mm: thp: introduce folio_split_queue_lock{_irqsave}() mm: thp: make split queue lock safe when LRU pages are reparented mm: memcontrol: make all the callers of {folio,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_FOLIO to lru maintenance function mm: lru: use lruvec lock to serialize memcg changes Documentation/admin-guide/cgroup-v1/memory.rst | 2 +- fs/buffer.c | 11 +- fs/fs-writeback.c | 23 +- include/linux/memcontrol.h | 184 ++++---- include/linux/mm.h | 1 + include/linux/mm_inline.h | 15 +- mm/compaction.c | 39 +- mm/filemap.c | 2 +- mm/huge_memory.c | 162 ++++++-- mm/memcontrol.c | 554 ++++++++++++++++++------- mm/migrate.c | 4 + mm/page-writeback.c | 6 +- mm/page_io.c | 5 +- mm/rmap.c | 14 +- mm/swap.c | 49 +-- mm/vmscan.c | 57 ++- 16 files changed, 778 insertions(+), 350 deletions(-)