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 8DAA4C433F5 for ; Tue, 31 May 2022 02:41:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 20EA76B007D; Mon, 30 May 2022 22:41:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 19A406B007E; Mon, 30 May 2022 22:41:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 083EC6B0080; Mon, 30 May 2022 22:41:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id EC9686B007D for ; Mon, 30 May 2022 22:41:38 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id BF4E16045B for ; Tue, 31 May 2022 02:41:38 +0000 (UTC) X-FDA: 79524487476.03.AD938E6 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf07.hostedemail.com (Postfix) with ESMTP id A583040002 for ; Tue, 31 May 2022 02:41:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1653964895; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dqGPJPGu5WN/i1V+mwA4aFt/oqbHUtth4ZkdMSpoL5A=; b=NHXJX/TP9QNsAIHgD/Pp/LJkUU7HmD3/lscdQ8nQDspMBdr/RPHXsRKElk8xKGUMZAf2OR IUzIKt2+emUugACeq814aE+I/m8cL0Yn9hsmtnQS3Z5ekNOYVUENSw1AnJ5EqydnXlIi2R 2+g43lWD1ElAtyN8ieSyGwoMs3HacOg= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-665-Uu4laDedP6yfga6ESTEaeg-1; Mon, 30 May 2022 22:41:32 -0400 X-MC-Unique: Uu4laDedP6yfga6ESTEaeg-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 849121C01B33; Tue, 31 May 2022 02:41:31 +0000 (UTC) Received: from [10.22.32.183] (unknown [10.22.32.183]) by smtp.corp.redhat.com (Postfix) with ESMTP id F22A6492C3B; Tue, 31 May 2022 02:41:30 +0000 (UTC) Message-ID: <1ecec7cb-035c-a4aa-3918-1a00ba48c6f9@redhat.com> Date: Mon, 30 May 2022 22:41:30 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH v5 00/11] Use obj_cgroup APIs to charge the LRU pages Content-Language: en-US To: Muchun Song , hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev, shakeelb@google.com, akpm@linux-foundation.org Cc: cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, duanxiongchun@bytedance.com References: <20220530074919.46352-1-songmuchun@bytedance.com> From: Waiman Long In-Reply-To: <20220530074919.46352-1-songmuchun@bytedance.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.85 on 10.11.54.9 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: A583040002 X-Stat-Signature: r1gf9xp1w6uws9p5fxqxqynsettfoydh Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="NHXJX/TP"; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf07.hostedemail.com: domain of longman@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=longman@redhat.com X-Rspam-User: X-HE-Tag: 1653964885-96450 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 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. Thank you very much for your work on this patchset. Cheers, Longman