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 237A8C7EE31 for ; Fri, 27 Jun 2025 08:50:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 81B756B00B3; Fri, 27 Jun 2025 04:50:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7CB1D6B00BD; Fri, 27 Jun 2025 04:50:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6BABD6B00BE; Fri, 27 Jun 2025 04:50:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 54E6F6B00B3 for ; Fri, 27 Jun 2025 04:50:36 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id D442BBA5F5 for ; Fri, 27 Jun 2025 08:50:35 +0000 (UTC) X-FDA: 83600559630.29.2515875 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) by imf03.hostedemail.com (Postfix) with ESMTP id D39EA2000D for ; Fri, 27 Jun 2025 08:50:29 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; spf=pass (imf03.hostedemail.com: domain of chenridong@huaweicloud.com designates 45.249.212.56 as permitted sender) smtp.mailfrom=chenridong@huaweicloud.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751014234; a=rsa-sha256; cv=none; b=NbYIFjQGRA0r6hu/Sq3dFyJgyyBxzViujcJGzmd3/JGWRzomr7g2wcSPOJHAnKujvA92FV xQ0pKOjhGHdlnGyd1jPDUbbbUfcMyU1eo3aW/iqPzF4Ro1ppL7QyGmJrmvZiggsBj/qQsF NC9CylNidB2iSltFdJjoWAN35q9dNTk= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; spf=pass (imf03.hostedemail.com: domain of chenridong@huaweicloud.com designates 45.249.212.56 as permitted sender) smtp.mailfrom=chenridong@huaweicloud.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751014234; h=from:from:sender: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=iOIbB2KUkq9r6LOacuka6WqWnszai7L0fo9X4lacUhc=; b=WSpl7vQfLHm9kDAk6ftqD49jSii92ThRMtPoVNx9e2v+7OsIX7zJHX4AJXg71Ub3VwPSig mDH3JAf6ep6x/3YCMs0IRz8IJV6YpsoJsIU7752S+rfSc8p0j2r6IueWodh7Q2UN4nxoQs bB8m5KWKp6KKRLNPrSVAsaMWqq7EFBA= Received: from mail.maildlp.com (unknown [172.19.93.142]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4bT8QV4KfSzKHMpm for ; Fri, 27 Jun 2025 16:50:26 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id F18FD1A1DD5 for ; Fri, 27 Jun 2025 16:50:24 +0800 (CST) Received: from [10.67.109.79] (unknown [10.67.109.79]) by APP4 (Coremail) with SMTP id gCh0CgD3pltPW15oY6k2Qw--.2149S2; Fri, 27 Jun 2025 16:50:24 +0800 (CST) Message-ID: <1b6cb2c2-9aed-456e-a803-afad9731cb42@huaweicloud.com> Date: Fri, 27 Jun 2025 16:50:23 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC 00/28] Eliminate Dying Memory Cgroup To: Johannes Weiner , Kairui Song Cc: Muchun Song , Muchun Song , mhocko@kernel.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, akpm@linux-foundation.org, david@fromorbit.com, zhengqi.arch@bytedance.com, yosry.ahmed@linux.dev, nphamcs@gmail.com, chengming.zhou@linux.dev, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, hamzamahfooz@linux.microsoft.com, apais@linux.microsoft.com, yuzhao@google.com References: <20250415024532.26632-1-songmuchun@bytedance.com> <20250417190404.GA205562@cmpxchg.org> Content-Language: en-US From: Chen Ridong In-Reply-To: <20250417190404.GA205562@cmpxchg.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CM-TRANSID:gCh0CgD3pltPW15oY6k2Qw--.2149S2 X-Coremail-Antispam: 1UD129KBjvJXoW7WF45XrWxGr4fGr4fWry5XFb_yoW8ur17pF WFyr90yrsYyFW5Xws2ywn29ry5Awn3ZrW3Gr45Gwn5JrnxX3W8tFyIyF45ZF9rur1xAw12 vr4jg34DC3WYyaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv0b4IE77IF4wAFF20E14v26ryj6rWUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x 0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7MxkF7I0En4kS 14v26r4a6rW5MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I 8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVW8ZVWr XwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x 0267AKxVW8JVWxJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_ Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7IU0 s2-5UUUUU== X-CM-SenderInfo: hfkh02xlgr0w46kxt4xhlfz01xgou0bp/ X-Rspam-User: X-Stat-Signature: dwbqiw4rp7mrygst4ybna1itqw1rye53 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: D39EA2000D X-HE-Tag: 1751014229-410197 X-HE-Meta: U2FsdGVkX1/47WZRxXB6oBHN+FMcUU/YRL2rAotR1+fAe5v0PmgqJ+kr9iPe42b/GgBJChglEBwMkQatE+nJq5mhHlTlhuU9cyv8PcG77CoYDC4CnXdN0cDXK4OTbLYFSvMxWvkDn3O9ZIufJPoNea4V3Qpdyihgu2lseFeVE/ft1XOdq6IR4llpcMStKozfHuUv1QTXoLTNW82TzvuE6yFa9Uq0IlLY0Vgo/cmUZQowTu5oN0J5gN6rcBbiR5giEUbXbwP3+j3tCWdws7sCzJK52HqIvAJdDXIdC88uKNWzY2Q+r2M/ql9W9+ZjKGYjQa4AMLTuu/bAVjynhO4Yq48+DHVAld1N5uXhH3uiwnmNSRJHA5ECEiAeYQwwSa9NN6Mm4qkNgJMLbImijvh+IseFMJgogwo8nB/7MEUzC2wHaH+5oWGHj9m0IkE6RMZXgwU77MM4cW261irx6H/f5T5Rozq6VTcVnZ+sxiSHr79j3gNro7zOjtF3Zr3mk7UotHgIYRShmw6eQT0af8xveItFMD1gBQwv6s0v+8RmiK/S0FIW6Ylec6jZzg7X/v8ziXulDPydBFYyukdJ/Os7cAZWb10XJ3ncSdq7QzEgvynZ+v176BWuXwDUFlbyO/PNHj7uZQDaoIV4QptAQTHvaLycOb4kecMWnD2kd4msekPN30GKCY+Uj+CAFD+s02xcXz85n10oDpnPAjneQtWZMtPpQK0qKDrzB7JsvlcBgvadhcaZ+SgmVFEZioC6p+e+ZMGX69qS4vNhYGUGLgp9SrGMu5UAAagbGmJzwvSOcmF1uIrg5BG1sg1o6ChD5xkv 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: List-Subscribe: List-Unsubscribe: On 2025/4/18 3:04, Johannes Weiner wrote: > On Fri, Apr 18, 2025 at 02:22:12AM +0800, Kairui Song wrote: >> On Tue, Apr 15, 2025 at 4:02 PM Muchun Song wrote: >> We currently have some workloads running with `nokmem` due to objcg >> performance issues. I know there are efforts to improve them, but so >> far it's still not painless to have. So I'm a bit worried about >> this... > > That's presumably more about the size and corresponding rate of slab > allocations. The objcg path has the same percpu cached charging and > uncharging, direct task pointer etc. as the direct memcg path. Not > sure the additional objcg->memcg indirection in the slowpath would be > noticable among hierarchical page counter atomics... > We have encountered the same memory accounting performance issue with kmem in our environment running cgroup v1 on Linux kernel v6.6. We have observed significant performance overhead in the following critical path: alloc_pages __alloc_pages __memcg_kmem_charge_page memcg_account_kmem page_counter_charge Our profiling shows this call chain accounts for over 23% . This bottleneck occurs because multiple Docker containers simultaneously charge to their common parent's page_counter, creating contention on the atomic operations. While cgroup v1 is being deprecated, many production systems still rely on it. To mitigate this issue, I'm considering implementing a per-CPU stock mechanism specifically for memcg_account_kmem (limited to v1 usage). Would this approach be acceptable? Best regard, Ridong >> This is a problem indeed, but isn't reparenting a rather rare >> operation? So a slow async worker might be just fine? > > That could be millions of pages that need updating. rmdir is no fast > path, but that's a lot of work compared to flipping objcg->memcg and > doing a list_splice(). > > We used to do this in the past, if you check the git history. That's > not a desirable direction to take again, certainly not without hard > data showing that objcg is an absolute no go.