From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1A70C433EF for ; Tue, 31 May 2022 07:29:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D5C2C6B0080; Tue, 31 May 2022 03:29:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D0B9C6B0081; Tue, 31 May 2022 03:29:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BF83C6B0082; Tue, 31 May 2022 03:29:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B0B936B0080 for ; Tue, 31 May 2022 03:29:38 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 8584B801CB for ; Tue, 31 May 2022 07:29:38 +0000 (UTC) X-FDA: 79525213236.19.8F783F9 Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) by imf12.hostedemail.com (Postfix) with ESMTP id EC61140078 for ; Tue, 31 May 2022 07:28:56 +0000 (UTC) Received: by mail-pf1-f170.google.com with SMTP id bo5so12461484pfb.4 for ; Tue, 31 May 2022 00:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ynHr+f3HdbTV3fIx5fiKz75mjaU0slPzyjQUZFWsNNE=; b=3BSBjnH3ZVmWwEIVHzHXEhghdgZpFnAo+yvYtAzpgRfIXkbyBVhTXgf5d/xjNpaQHS sz0UFZvQzv5e5HRgAt9iGDSpGTZx9tTCiezIhnMbEdJOAJ7K+A0IMSH0rp5jdGF1tm8K EIrFKWV2qoxlzowMCVlAVqGHTETYK99rGlF5k+vSuVBHe/TdQ3E8MnxKfl9JfYEjOtJH gnrlRHJsGlcnnMfhwsuKx9xFyDr/GEvdyf13nvjHmdiDKABo1mgxQFAJZxSAAZaNhZhd NeqvDimuZDLbss4uGUDTImQXiGHwgXTn0NpL9vNjO1nvo7gCeAaXNnUrMKHbLulytSh2 JmIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ynHr+f3HdbTV3fIx5fiKz75mjaU0slPzyjQUZFWsNNE=; b=MXNij0qm7OCPogFtQMskkbb+4ggxyzkThW1msqUf0dA5J6vON0RiguuX1Ix2BQ1Mbb jPngN+jyR7CHBXX4tUEF82LdVL7sANkWipUxpnqdKpV9Uwz/A4RzjSoasabYAeM+OLGU 6Dgv6GJv6sZyGTc9ZGeRMcgJWodvSe3KQ5rjnkIDlSjrWfCTz0o/UYNzozpF1jfX/fpS fLl1aLsLKUV/JG7soYb/qDqC5MvyaTlqrbQAV3drSfImk9hG5w77LCupMmbDqmYcc8gA HTH0kMVUC32aSDiIC2S6Dy+arEqGqqtsXEP/OoOk+Gc2rkbfHkTkMaztQEYmdqfkmy9d uXFg== X-Gm-Message-State: AOAM5330LkEFWsdgIriQoJmYP1O0B/xCpp5qC+utcW3fL69WhlFKZAER iRo/soKo6ithgbp/cfgKCpGgdw== X-Google-Smtp-Source: ABdhPJz+sPjbBPJuUyu8J0KCWi2CcYAAAGGaUdZO4DWuoXNJnb+8eFlVVZ9wEVss1F0lkZnI3TSv0A== X-Received: by 2002:a63:7156:0:b0:3fb:fa23:480e with SMTP id b22-20020a637156000000b003fbfa23480emr9579581pgn.553.1653982176034; Tue, 31 May 2022 00:29:36 -0700 (PDT) Received: from localhost ([2408:8207:18da:2310:94c7:fca6:824f:4dab]) by smtp.gmail.com with ESMTPSA id j190-20020a6380c7000000b003fbea5453c5sm4901384pgd.9.2022.05.31.00.29.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 May 2022 00:29:35 -0700 (PDT) Date: Tue, 31 May 2022 15:29:27 +0800 From: Muchun Song To: Waiman Long Cc: hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev, shakeelb@google.com, akpm@linux-foundation.org, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, duanxiongchun@bytedance.com Subject: Re: [PATCH v5 00/11] Use obj_cgroup APIs to charge the LRU pages Message-ID: References: <20220530074919.46352-1-songmuchun@bytedance.com> <1ecec7cb-035c-a4aa-3918-1a00ba48c6f9@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1ecec7cb-035c-a4aa-3918-1a00ba48c6f9@redhat.com> X-Rspam-User: X-Rspamd-Queue-Id: EC61140078 X-Stat-Signature: aapeapi18wsyyignaffxabydyzmuu8qt Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=3BSBjnH3; spf=pass (imf12.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.210.170 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com; dmarc=pass (policy=none) header.from=bytedance.com X-Rspamd-Server: rspam09 X-HE-Tag: 1653982136-67909 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: On Mon, May 30, 2022 at 10:41:30PM -0400, Waiman Long wrote: > On 5/30/22 03:49, Muchun Song wrote: > > This version is rebased on v5.18. > > > > 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 > > > > dd if=/dev/zero of=temp bs=4096 count=1 > > cat /proc/cgroups | grep memory > > > > for i in {0..2000} > > do > > mkdir /sys/fs/cgroup/memory/test$i > > echo $$ > /sys/fs/cgroup/memory/test$i/cgroup.procs > > cat temp >> log > > echo $$ > /sys/fs/cgroup/memory/cgroup.procs > > rmdir /sys/fs/cgroup/memory/test$i > > done > > > > cat /proc/cgroups | grep memory > > > > rm -f temp log > > ``` > > > > [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/ > > > > v4: https://lore.kernel.org/all/20220524060551.80037-1-songmuchun@bytedance.com/ > > v3: https://lore.kernel.org/all/20220216115132.52602-1-songmuchun@bytedance.com/ > > v2: https://lore.kernel.org/all/20210916134748.67712-1-songmuchun@bytedance.com/ > > v1: https://lore.kernel.org/all/20210814052519.86679-1-songmuchun@bytedance.com/ > > RFC v4: https://lore.kernel.org/all/20210527093336.14895-1-songmuchun@bytedance.com/ > > RFC v3: https://lore.kernel.org/all/20210421070059.69361-1-songmuchun@bytedance.com/ > > RFC v2: https://lore.kernel.org/all/20210409122959.82264-1-songmuchun@bytedance.com/ > > RFC v1: https://lore.kernel.org/all/20210330101531.82752-1-songmuchun@bytedance.com/ > > > > v5: > > - Lots of improvements from Johannes, Roman and Waiman. > > - Fix lockdep warning reported by kernel test robot. > > - Add two new patches to do code cleanup. > > - Collect Acked-by and Reviewed-by from Johannes and Roman. > > - I didn't replace local_irq_disable/enable() to local_lock/unlock_irq() since > > local_lock/unlock_irq() takes an parameter, it needs more thinking to transform > > it to local_lock. It could be an improvement in the future. > > My comment about local_lock/unlock is just a note that > local_irq_disable/enable() have to be eventually replaced. However, we need > to think carefully where to put the newly added local_lock. It is perfectly > fine to keep it as is and leave the conversion as a future follow-up. > Totally agree. > Thank you very much for your work on this patchset. > Thanks.