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 D544DC3DA4A for ; Fri, 26 Jul 2024 15:47:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6DB866B0098; Fri, 26 Jul 2024 11:47:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 68BAE6B009A; Fri, 26 Jul 2024 11:47:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5AA986B009C; Fri, 26 Jul 2024 11:47:07 -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 3CAA46B0098 for ; Fri, 26 Jul 2024 11:47:07 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 94A3C1218B5 for ; Fri, 26 Jul 2024 15:47:06 +0000 (UTC) X-FDA: 82382332452.05.8B65933 Received: from out-181.mta1.migadu.com (out-181.mta1.migadu.com [95.215.58.181]) by imf06.hostedemail.com (Postfix) with ESMTP id 933AC180022 for ; Fri, 26 Jul 2024 15:47:04 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=i+IgIvZW; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf06.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.181 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722008784; a=rsa-sha256; cv=none; b=s4EXN3vxOAoM0X38H98nlKXod9OVGYrNampvA6tT3rJEnVx/ysHca328dJwxyhkNre++i/ S4jEq8Fa9GaamNQr1p8j7fSA2KkWTzwYPEB4Rq8Yc5wU54g8zjCeTiZ5LoGJMBE4SG1mC/ AfH95WzkmJIdsZM1FAvUCsYgLF3HEqU= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=i+IgIvZW; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf06.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.181 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722008784; 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=QaTFp+0mxeLoNEiix+ZWdffU29+TDb8EWzJkPAoeWKc=; b=uDU5V1R7lhxF+dAMkwlrOC/I28ptr48gxdKtr9Qub9LezPh8a2cuqp4g/X39H0L+h5UD6+ 3fvuh6TmB29oYTjXw8w8xmBEkAbRZzfXxNhDovLmgyhXb8gYCBqD8X5fRrzqKBU4W+xQ1M CbDQaV36/ACORlpZykU61s9L7DdxMvI= Date: Fri, 26 Jul 2024 08:46:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1722008822; 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=QaTFp+0mxeLoNEiix+ZWdffU29+TDb8EWzJkPAoeWKc=; b=i+IgIvZWG0ZD89UQ/dRTG03f0kpvqvNrFV0P4CLPyp5BfGQ2EXRocAVx/XXNXcfUQKdNL0 bJ3sS4vgTRJtTz8npHctWqaPph7+uHn8o51ku2n3DR0s5IoI7/ntAaB9T92CDsAux5kQmG MaP3Ymk9ewOwY/MVcsk34H/PZEsYr10= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: "T.J. Mercier" 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 Subject: Re: [RFC PATCH] memcg: expose children memory usage for root Message-ID: References: <20240722225306.1494878-1-shakeel.butt@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 933AC180022 X-Stat-Signature: y4tdd6febo3ia3oqsn57uqpck53wqwrb X-Rspam-User: X-HE-Tag: 1722008824-46688 X-HE-Meta: U2FsdGVkX1/ePV0RA2bCeVShYjNeoqONGmrMQ4OyVk5CrQV9Q4uyh/I3wunobngbed1xyflADOWvSY2xt3jsnzhfPm2GfO5IirdjJy4yyBAO6j9215afqzn3JcEoYBLuKHO2OrO+MvDr2EfUt2I8B/Vf1nY+gGZfSFno8zOKC7k9qxrTzK25ljqM80+6jK6eifm2lBZJrPt4AfRsemgsttIPi7vJY6pc1/tVb+CePTlhJQlV/8T/eVyy/xubAwfcfeg4oAgKf8DcZ3wXh62zRxA1VGbpFZickVOw1qCI9D3HhEs+Mr2TL4lHer4ZDiZUGZVA2M5y4K14B/ilA7cPewLAhADzkaCrx9BxqjGURk6BJPv9xV4i54Uayz5cvCLN3Wvc0m/0OHzqyHcF7YBnaPHo7d7Hwm3HQRHt0FMwb/W1w4QPIiiXlWqJ8ysV9cDvJ7LhAtItdZJxxcOJMR4s0MNuB7Z4aaz40xpGb9FJfMgGYwnMP1Y2FDXgXyHhICKEfdw+WXAj09keYrJvvwGP3zmmtW+DFYDNG8/xHuCN5shRrx51IB8y3AIIJMO31bC0z1STkH0rVytrdp9HjfGnuln77nEw1X0IEUp8Kh/LtlF8Kk9/J3U2saZMNexZKBxPLZ+2255gCEmUVdKXTdYQtwHftqdrtKfjkgLkUakPU6EZenHWFjXPheeVzEMXItx77VHSiZq4XDY5clcOQHLreM+F7+JIgYQaoXXz6qP5kCe0I0Mht+UxRlQPikmHyiSMdT6iwOCjPdjIhkf3jdSFjhhRC/IJMYXTAPoBbhGIwinvUjFvYDRBJPQj8c+nzphkkXgsxLvu/2j4SdZxnkCwBi5GWbvyTp/u467ZrJAEMZwzZ2oq31JNjtUqhsF9QRELKSmTlMxEd3ywf3wsDw5XXAmDAwg5xuuM+FzmTLVSFKEoZEo82DfBdPr7bPWlb4pAkzAnjuVzTFeRSa6j3XJ EL//21iG unxx0Cj7vrBfwRbNpDHo/qi4aWV5+TZ8OGQR6choApt4bHLbMtrq0UhlfikpisQMTL373aKZSv+Qg1W1gyHP2U9ozQWfMC4x7uYYAERav0Mk0Ji+2WHOoMn/fohcTSffLrKKxntXFsYV4D/J88BSPM0N6JQ== 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: Hi T.J. On Thu, Jul 25, 2024 at 04:12:12PM GMT, T.J. Mercier wrote: > On Mon, Jul 22, 2024 at 3:53 PM Shakeel Butt wrote: > > > > Linux kernel does not expose memory.current on the root memcg and there > > are applications which have to traverse all the top level memcgs to > > calculate the total memory charged in the system. This is more expensive > > (directory traversal and multiple open and reads) and is racy on a busy > > 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 the > > 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.current > > of root and non-root will have the same semantics. > > > > This is an RFC to start a discussion on memcg charging for root. > > Hi Shakeel, > > Since the root already has a page_counter I'm not opposed to this new > file as it doesn't increase the page_counter depth for children. > However I don't currently have any use-cases for it that wouldn't be > met by memory.stat in the root. I think difference would be getting a single number versus accumulating different fields in memory.stat to get that number (memory used by root's children) which might be a bit error prone. > > As far as charging, I've only ever seen kthreads and init in the root. > You have workloads that run there? No workloads in root. The charging is only to make the semanctics of root's memory.current same as its descendants. Thanks, Shakeel