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 587C4C3DA49 for ; Fri, 26 Jul 2024 16:26:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E7B406B0096; Fri, 26 Jul 2024 12:26:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E517E6B0098; Fri, 26 Jul 2024 12:26:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CF29B6B009A; Fri, 26 Jul 2024 12:26:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id AFBFA6B0096 for ; Fri, 26 Jul 2024 12:26:08 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 5B139A1909 for ; Fri, 26 Jul 2024 16:26:08 +0000 (UTC) X-FDA: 82382430816.02.CBE09C7 Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by imf01.hostedemail.com (Postfix) with ESMTP id 709B740031 for ; Fri, 26 Jul 2024 16:26:06 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2wJNoC5+; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of yosryahmed@google.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722011164; a=rsa-sha256; cv=none; b=cz4oZc9oBI69hDHMX3Y8xrQEe9KJ5vvsg90++zq4oq9YEDlJdWnGDa3CbhOwzbf6MtdsTu GgeeDFbcCIl1+OKUBnDPtGg2VHN06KCBy5nn6/JF91d7y31xlNeW2eZ0dYsv2ezlyO29qL IyoqHYBraQ54aPvDepMitL1RQo7+Ix4= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2wJNoC5+; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of yosryahmed@google.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722011164; 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:dkim-signature; bh=A0HotuOlEhWe0MU21I/kfhWImzGIx856Iua/uZw/vls=; b=OtiALbDU+nh7COdK+a72U3gpH4TwWkyycC4f//ZLMBFFA8rMc5DrdYiATqrUbYiuF1zn0b PuXLXLmVkufU4NRwR9I4WC3z6iKbNwMlkLQDgEKYAWPjaTshjA5HfKF6dt5gb/d8vJh/nE qHok+Fam3fROsdvEf8p3HSujl4iWnKs= Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-52f008aa351so2178865e87.0 for ; Fri, 26 Jul 2024 09:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722011165; x=1722615965; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=A0HotuOlEhWe0MU21I/kfhWImzGIx856Iua/uZw/vls=; b=2wJNoC5+/mElNhCLYvVhtkrmjGdFJOAhmZRTUnNiVKuryj3R/VoCLvd+7D9zg4ZffJ zzmyjAgnNoUdTa10jtNUTA2eOjNiG7Py7kEDSLYfYt7CVEtXxVnPNfmO8wBLX6K/+iI2 2ZTMijYrUvnSZL+lX6viVqxghtKScxTAgpHrQZByx0M1jy8LlE6qzs5Nh7QPHpNJ4wXc XeBQQNARad/9tHbVFWdX9G3QnClXlKHYWmSeseVErveI46ptmxV2neV3mnLj7HXHFCmE LWtb/59WgaJHYil1V/bagsg4y2LASTNiXnWhXQrqgQ5ocHK58ZVgMHlWa+yQ85n15SDp 0AGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722011165; x=1722615965; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=A0HotuOlEhWe0MU21I/kfhWImzGIx856Iua/uZw/vls=; b=nL/kEoMlbkPOxoeVXn6e6XmAXsTpCN7Rt17ig7/9jrvaOfW2SCCibejYfxN3G9aw2H /0iyOdJsmAwVwRXpPYd0KeVlwLOFwi6dxsGpAl5uFBalYi7Zsca06PwlN2G+hRE3VMjG HYYAvIXbMT9m+NoAPoWE9oZhXrLWqhDRv3pnYBMsnjxQZmdYSi51rEkWKUfRBat4hNUv BrLEqfEfME2Qjs2cG1bb76VvO1XqRBIzu2HeXYecbhhuFdArLAuCrg/XEtO93ZKMmSyX X17Y6WHq7GlFYu4HAGNwf9/xzOAuhcyLmviODDhBFq3ve8cw2zWFv0Y6b04JzALLpeJY gEew== X-Forwarded-Encrypted: i=1; AJvYcCVLgtwFoQ6QAcyobRmsEVDWTv1JmDffjqxmpBKOx71ddSj0YYIDdOm6ja6ITpuhvQ6ulFilZzredUrifGGcFBqjeE8= X-Gm-Message-State: AOJu0YwctpNh9dyVN8n4qlezmE3nGA1sL2RqCD/BCIWuSaM+wHSECN5X zvmxiYnf5qUw7Beb1sjZwsQX5hRICkIloOoWVtF8Z/fiQ+VvWO9y8lyUvwnzedN4XsHmCCRPZ6J upsf4hKrPAK9q1xPCLbqySTvhCMx6q5BPLWvo X-Google-Smtp-Source: AGHT+IE0xKwFZ4J6T9MLf91CjF70ZKTDtKO/pkaYa9QKl4enwp412VzKpF/js//canxrgU+eLM0aCm2zsQqjZgQXHJg= X-Received: by 2002:a05:6512:2508:b0:52c:dcab:6738 with SMTP id 2adb3069b0e04-5309b25a344mr222643e87.1.1722011164051; Fri, 26 Jul 2024 09:26:04 -0700 (PDT) MIME-Version: 1.0 References: <20240722225306.1494878-1-shakeel.butt@linux.dev> In-Reply-To: From: Yosry Ahmed Date: Fri, 26 Jul 2024 09:25:27 -0700 Message-ID: Subject: Re: [RFC PATCH] memcg: expose children memory usage for root To: Shakeel Butt Cc: Andrew Morton , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Greg Thelen , Facebook Kernel Team , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 709B740031 X-Rspamd-Server: rspam01 X-Stat-Signature: 6cugh6yqie5euoj94b7xw6nzwxmiws7t X-HE-Tag: 1722011166-282526 X-HE-Meta: U2FsdGVkX1+evs58XfNlQ5LwsJcfem/1tLSji5hKd+Ga70IUFfe3zcU3v0j+6Kg8OrAqE81Hw/uPcbjwVSxUyqibQtaxXx0+jXERxwC0aJF1MdgXZicXJ57SDa2QvTpS8XszS/WX/Wh5TgMvRK6Tjercm9xf5YQz3qG6KfDj61cgeb034WLingtr66ArGqlgF3MiXVLAZT2dUcjgaKjzPySctQkNgcK1G1BoUa7PwQPme5+iQDHHy+JfoqHt7/PbqCSzcgQr+o6wQFJlpvVcYx0ol7Mn4J1bHMPuTOQxbr5ufkZ+K4uFp1bafraAtSETXGFE4qa15AXP3j749LmKw+4QvXtxxI84JalqwcFcr57lq7K6Lo4j3vbrKBhZY6HeEgR699aaR/tna6XRZOQ/8II9Di78twf1kh9yauGZl3m3qLM53+BIV4FB3SOjZZPGOhMXo/3M622558ENARtrr3yU4wEL1aqQQ9nw54wvU8NUWmTPkq5sbTdWUrS/klo8bYV/lOVo2227gg3RvgCBu+HEYyzfGvooLjaR9MxpfNBTv3JovQM0dM7uGJ2PioiPtMp734eMnaX0ZII+fZVUTB0YyW8JAq4A002Wl6F5pMhH+U33bJUXNrwTQ2fP4uHiZiIhvTheSmAEOzXcQ1XUt+z9JnrMSrZ+SxQwWrlTOpQYr8d12ZISTeEyOd4Ydf4PxNA9snetSdnAJO4epJYSo9MTKGVhz/ClJgPuR28b7e89YJTC/fq+b+WOl2gQRdmAMLlI1zO9rOawRm9NUTb1bF2BByw8c2PDQ/mod2t8dBtbLl9jd4ES+1qahE9foEMqMMpC/QhtQU2jP51aaodG8bGGOXIAxEgbJPKZ2wCMVPtmwg905SWGU2r94a0AxKiHe8pCJlSQEJCDpz2KdoXx6fjIo4yHdiIVmcFnsJroA0IQTDR7t5/ObC/edlAAl5RZe/7YxGqDXxI/BuL8tuB w65HaXYG IzyigI5R1tDAfLuULoGx87ijNSuZ+YfhRwYsW5Brekg9qC/yIdckmyXAQg/r8RY2QKhVrbH66aqrm3NDcLIYVTOddwz3LbjD+3bxLptXvznU1klG5tDV/6nE9antXKwzsodP9AiG7jN+BK/hhBD/ysIYroSCYIxNidUrOp7k3Llu3jYs= 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 Fri, Jul 26, 2024 at 8:48=E2=80=AFAM Shakeel Butt wrote: > > On Thu, Jul 25, 2024 at 04:20:45PM GMT, Yosry Ahmed wrote: > > On Mon, Jul 22, 2024 at 3:53=E2=80=AFPM Shakeel Butt wrote: > > > > > > Linux kernel does not expose memory.current on the root memcg and the= re > > > are applications which have to traverse all the top level memcgs to > > > calculate the total memory charged in the system. This is more expens= ive > > > (directory traversal and multiple open and reads) and is racy on a bu= sy > > > machine. As the kernel already have the needed information i.e. root'= s > > > memory.current, why not expose that? > > > > > > However root's memory.current will have a different semantics than th= e > > > non-root's memory.current as the kernel skips the charging for root, = so > > > maybe it is better to have a different named interface for the root. > > > Something like memory.children_usage only for root memcg. > > > > > > Now there is still a question that why the kernel does not expose > > > memory.current for the root. The historical reason was that the memcg > > > charging was expensice and to provide the users to bypass the memcg > > > charging by letting them run in the root. However do we still want to > > > have this exception today? What is stopping us to start charging the > > > root memcg as well. Of course the root will not have limits but the > > > allocations will go through memcg charging and then the memory.curren= t > > > of root and non-root will have the same semantics. > > > > > > This is an RFC to start a discussion on memcg charging for root. > > > > I vaguely remember when running some netperf tests (tcp_rr?) in a > > cgroup that the performance decreases considerably with every level > > down the hierarchy. I am assuming that charging was a part of the > > reason. If that's the case, charging the root will be similar to > > moving all workloads one level down the hierarchy in terms of charging > > overhead. > > No, the workloads running in non-root memcgs will not see any > difference. Only the workloads running in root will see charging > overhead. Oh yeah we already charge the root's page counters hierarchically in the upstream kernel, we just do not charge them if the origin of the charge is the root itself. We also have workloads that iterate top-level memcgs to calculate the total charged memory, so memory.children_usage for the root memcg would help. As for memory.current, do you have any data about how much memory is charged to the root itself? We think of the memory charged to the root as system overhead, while the memory charged to top-level memcgs isn't. So basically total_memory - root::memory.children_usage would be a fast way to get a rough estimation of system overhead. The same would not apply for total_memory - root::memory.current if I understand correctly.