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 6668FC3DA49 for ; Fri, 26 Jul 2024 16:47:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E8E066B0095; Fri, 26 Jul 2024 12:47:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E20DB6B0096; Fri, 26 Jul 2024 12:47:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C913F6B0098; Fri, 26 Jul 2024 12:47:03 -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 A067D6B0095 for ; Fri, 26 Jul 2024 12:47:03 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4F54EA6C37 for ; Fri, 26 Jul 2024 16:47:03 +0000 (UTC) X-FDA: 82382483526.15.1D66ED4 Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com [209.85.219.171]) by imf18.hostedemail.com (Postfix) with ESMTP id 7B44F1C0027 for ; Fri, 26 Jul 2024 16:47:01 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=lBec6qOR; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of tjmercier@google.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=tjmercier@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722012384; a=rsa-sha256; cv=none; b=68WHRafMxP/t2hYy39JCsnSsJI8fmqDvmi3sWKLxcqbvWv6uNyA4t9ig6l7XtMKYcnqiK/ 6xZPxAtq/wwL9qF7mKwCghVxKBimGxptMIqnXBng2b0UCMFmO570eVWpse0VUaXV38X8E4 cBuAxKEmaYWaCttbRUU4WoHhLCi8mgY= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=lBec6qOR; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of tjmercier@google.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=tjmercier@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722012384; 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=VsX59mPgZtrEie39/GZ8ygIZ9hc+816v+5X04tjRwYI=; b=uz7w9HNn82dk3Byp7QCjnxeTTm9l4qmc+msM8f1AHbevS6yjs/1DHp32bhDhBkjirrcy1i s53XaJGtlhktS6S+V9/IWvrUavOcaIupURvJzBoxSwbo3Pf7zcDU3r/5StHuYIWLMlj7UF rlDZRgrmc62SGaX0Ebkh0njVywfQNNQ= Received: by mail-yb1-f171.google.com with SMTP id 3f1490d57ef6-e05eccfcdb3so2035611276.1 for ; Fri, 26 Jul 2024 09:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722012420; x=1722617220; 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=VsX59mPgZtrEie39/GZ8ygIZ9hc+816v+5X04tjRwYI=; b=lBec6qORVgC2PmaNz89LW7+jaaFvSEOLTg613Swc2b5kgLSSpOyti5PnKdO3wZdUe4 zbfCIBeJNERzTdtzFuAq7EcacDbxfXRRH1gMJQ1BP+BJOoCIoD9sNtofooNxKxhkji6X i/vTRkkxfTaMAoQkCEJpAmJinTw/Y2NrJ6NkfXVTtODgTjBcebK965lcLBHLLkofXEBs B4NF6LMwb6GEGA5WJCpYvm7bPVj8zVVjsvKZQW7AsgdPpf3b12c+qpED+HATVA/7QTNc H1qchFyyDF+wRom2xKf97wRIPyUpjTKYRqE9x5pBE1Yf1b3BAGUE5nUCnE1J8F3oRs6a kUNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722012420; x=1722617220; 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=VsX59mPgZtrEie39/GZ8ygIZ9hc+816v+5X04tjRwYI=; b=BFFiye6wVKuS//bOWO9Adw65ZPj+0/dMdVfiIsCuIqnEc+Et8QziYlwiqlX0/xmCyF wMs18BXGUINQMH/Qz27njTvdH2595CvUDWvBoic3/0pGpnByLZK0yf90tN4gzZRISHLz y33XOFJq7TpVUZnvKWbB8jNL7Umkheg5a8pvKCOawmBGusDFEAVKHV4oaKmGi2EPx+8B nlTwDqKgAWyPGwtrcqpaM7VWb5K6Ptm5Cej6bt9t1GEwu0WQLyNDWiozJF+fDQroB/sH volZdq6lR+/y85FNlyS4IXfXlr4LUgv+lb+ciMf5srbTy3cXrPFHOBizkYaE15amDPfy nOJg== X-Forwarded-Encrypted: i=1; AJvYcCULtUNHkXbmxNKnYM9K5i4v47kTdgW/4JJ1uZ9Ak5QUG7cxEZudM2MARhR8+WczNYY6z0RoxG1xPFoDQdnzji/Psus= X-Gm-Message-State: AOJu0YziUiBwkDBD6EDpCFYRgy8lp6Yb8goiuqDu0nBXeQg2bl9WSy1x n/vgRNnOjvNKAuzUO3OBbT4Vbhdu4xyUXpo9PZuJAjZppUkyuPwb7yTHzYYKdHeEe01jV1+9fI6 VIux2uxFye+4pc2EM5B4Eb8XQdXzGXGJRjA5a X-Google-Smtp-Source: AGHT+IHvjARSHS13OyZRvXmxTUtGDoqeMUEoVpKPSZdXCI6sy/VtejyKKxC30+vNfneTHF35XYilujQgIJqHT7UU1to= X-Received: by 2002:a05:6902:1028:b0:e03:3598:2989 with SMTP id 3f1490d57ef6-e0b545bffe6mr372203276.45.1722012420186; Fri, 26 Jul 2024 09:47:00 -0700 (PDT) MIME-Version: 1.0 References: <20240722225306.1494878-1-shakeel.butt@linux.dev> In-Reply-To: From: "T.J. Mercier" Date: Fri, 26 Jul 2024 09:46:47 -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-Rspamd-Queue-Id: 7B44F1C0027 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: bnwzx8skcjp6n3enrmjfmg81drxkmxcp X-HE-Tag: 1722012421-33984 X-HE-Meta: U2FsdGVkX19gDdiqscyGOQdk++DRHQxWRaRaz050BxpO6BkD8/JFslNe6u/xlm3rJPGrrl695IwpnTpKQcrzO8W6qE2upruVz5m3/Fh6Co/thi2VV0FYB12Ykd8qT4v4VqMyEkBV7rj/joW+El/UUyme+R80fLUVAhVLqoaJl2uUia87KwimKCY4ZEnXwAaAr3oWutB0xYCFFtmYDJRNwV6fiIeJfL6Tjd2MBu73nj3VS+KBICKtrQZAcD2w0lKio3cPcTwvB6KA6CJ1dg9ukt5WbefdFnjsePLvZIETssFMCOHOIC+PxQMJP6pTUHOrvqgMlQ81Uh/JQaLiwUH+g+jKWoRKtcTVS34vO8wmioPymH6suu2i7Lcn1DDw+I7q04jzM4rHOBvvTpWMvHaFYFU2mQU0bQtwtVMk1vLingvIlHOT32h2ah2k/W3gZN3xM5JyPDmqgR2Bq2+InmsG7JNaXasHCBtdklfD1mEamBk1JrbBFyP/SV4PJV2IEfTg5iMrMB45zxLn8B7JBQtqHIs2ANGjfaNUa62TvIdOG4BrPxmAyhyUHWQ+PNpFqZWsajqSlJwmDwgCCOkXtOtADiWVQRwv+pQ4/A9W1JxEad8+03915XFOcp17faeeCfbqRhW+99N3zD19yUSKv8tXVACNVbAfRe5cJjxmOrh8M8XaeQNHS2b8CcLsDzUdW6O/Vl69OK/nGlI6trMxdziltEprHbjGR8p+HPRsGMGs2xJ4Ftkgdwo2aP6fK7bMIjrejY7+zaM2GfGaHPL+YV9VD+ZxD0Qt/H4fske7SaUGcOeOvDT/+pPYjADZl7Y/XL2PGAeWIz0z8hx71ZVFkm9gsEvCyDO701h4z9vFlWmnWvBH1rCdTbh1cfI1Q/TiT9LAerSbUHkwwHh9e5winQQIh4XjTaQ8lupdd8A0OFrH3q2wH0IOU/kYkFgqMYpvY2rPv/SHYuJ9nAaOp+imHTT XRCllJAg gMx6Xlry7+dIhrry/kvD1E7xaBrA8vrI1R72sqlBzAp/+IwMI+S8idGIrDfBppfNEOI7PjFIJItfW7TvqpfckoCueXumTtAXluQfCPTK3PLhd+JisE9FbOlnA4ljO6csOKFqUTfDIAP83/ta2PQ0qhGm09XJl5zcnr0bNpuu12osM0WM= 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:47=E2=80=AFAM Shakeel Butt wrote: > > 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=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. > > > > 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. Yeah that makes sense, I get how it'd be nicer to do just one read in the root instead of digging into all the children. I just meant to say that when looking at the root, currently I only care about a particular stat (e.g. file_mapped) instead of the whole usage. > > 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