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 1DC32C433EF for ; Thu, 23 Jun 2022 16:55:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9505A8E0164; Thu, 23 Jun 2022 12:55:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8D9B18E0144; Thu, 23 Jun 2022 12:55:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A09D8E0164; Thu, 23 Jun 2022 12:55:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 646408E0144 for ; Thu, 23 Jun 2022 12:55:46 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1ADEA203D4 for ; Thu, 23 Jun 2022 16:55:46 +0000 (UTC) X-FDA: 79610102292.04.D87898D Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) by imf19.hostedemail.com (Postfix) with ESMTP id B3B9B1A001B for ; Thu, 23 Jun 2022 16:55:45 +0000 (UTC) Received: by mail-pg1-f175.google.com with SMTP id 184so19673846pga.12 for ; Thu, 23 Jun 2022 09:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zxNuJF6Nbe8LLHbYqIbwZg9Zj1L4NANG6tNglCp+Qvc=; b=XHUVPgvbh1RbKwDTYzng/n5/obx4NKF4t5gJwAYybq7iw0yl1IDnJnj/UY6lbOdIcC JkaxYapcyaMhT7hyRjqzXPDIvNUgOB31tZlsO0LlgDI/TYnfopMr1Zeep1u7xtng6c7U Sm3VvZm1doZ/hhaqr8Q85AwjJvT8qWBqtgoRDufLJDPWRTqeYWW1HMtPPhtpNvrt51hn OzAAz9xbjUVszG9brdyyjkJOuSgnHuvZ6zm2eprL83/CPtn07FUuEfi6zGOrWwOkzBjA pYCc/T8UNb0tsN+TWWA7O5ktS1EBpp22pfEQuQWcMcqlVh/8XUXFTzRxBRfxmd9MTYgU 9zuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zxNuJF6Nbe8LLHbYqIbwZg9Zj1L4NANG6tNglCp+Qvc=; b=KpzSPQxqqKY/r0SyP3s7zfuHk/2mCRRHKjDpRE6Hq+UFN459ABXLl07/xitX5kEo6G qyqtJYEgP5VwLI3v/CnepUJIT378IRlwGHch+WzMO++uN6qgkxhq1lTEs5GBEZrCnASv Q1gu6pzqcEB2LI8w/zfcDOYgt0Bb9WZyKV2slOte7fhoauCITpOgAA173RELXwiiJ0oC YlkRDUDfVyvNEV5M39rSdtPjV9ZqImZCZH8l8cHuh/wt9fs5FtlKHE4Dhn3aGkjMQsVs WoskzlcuHhZeyv44jgygP5I9o89TZM/v5tk0R9DYEYNzRom6/P0TK12xNyKCO6r+Fqz2 mVEg== X-Gm-Message-State: AJIora+zB2KleEtP75DIPlcebClSUlcqSBz3V9H+3w/TH11HBXTv9wVx cFc1cOxvzuox6ZW5DeoMqeV6TWcOX+NqHWRI+3GXMEmoyDY= X-Google-Smtp-Source: AGRyM1tEW//oYgmqBPHq48elIVVWT5t+ubvinbX4G1Hc6hZJrESk88dK9Jd6fyiayXLcRsWyQhixpLKJ/IPg7eKqTKc= X-Received: by 2002:a05:6a00:2393:b0:524:eeb2:5547 with SMTP id f19-20020a056a00239300b00524eeb25547mr30203002pfc.8.1656003344568; Thu, 23 Jun 2022 09:55:44 -0700 (PDT) MIME-Version: 1.0 References: <4e685057-b07d-745d-fdaa-1a6a5a681060@openvz.org> <0fe836b4-5c0f-0e32-d511-db816d359748@openvz.org> In-Reply-To: From: Shakeel Butt Date: Thu, 23 Jun 2022 09:55:33 -0700 Message-ID: Subject: Re: [PATCH mm v5 0/9] memcg: accounting for objects allocated by mkdir, cgroup To: Michal Hocko Cc: Vasily Averin , kernel@openvz.org, Andrew Morton , LKML , Linux MM , Roman Gushchin , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Vlastimil Babka , Muchun Song , Cgroups Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656003345; a=rsa-sha256; cv=none; b=oALCQ5qCL/VcTeG2s0GSSW5FzcMH/qftGIGsHO5P1Ve1/scfRQwwTQ+jwjrj448n5p/b7z FtD8fFIAsX29G/VKP7b3VUgCgvBbztZliAeClikV3UbPnobj8PrECJp8V9T0K/k9z4Cy18 G2Bz7hv7g5hcoiauK9FhOJC8K8PdnSc= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=XHUVPgvb; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of shakeelb@google.com designates 209.85.215.175 as permitted sender) smtp.mailfrom=shakeelb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656003345; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=zxNuJF6Nbe8LLHbYqIbwZg9Zj1L4NANG6tNglCp+Qvc=; b=bJqSHEPloIQybm8CtROtSW0YibxN0KxIKDW62LbSYpg6uEMkriOEYH23tWqypn1ZblqexW GF/96B0JLp3safKyYanzBMz8fiAt9XlCT73wcOPxyv4JY930XpOZlIftPVS4F3w7U3K/Ku e5QwYQKYHC18pJdF2mtDdXAAf0Y3MR0= X-Stat-Signature: b3rjmmbr63ubgfikne3thz5dqjz4o47g X-Rspamd-Queue-Id: B3B9B1A001B Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=XHUVPgvb; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of shakeelb@google.com designates 209.85.215.175 as permitted sender) smtp.mailfrom=shakeelb@google.com X-Rspamd-Server: rspam10 X-Rspam-User: X-HE-Tag: 1656003345-70009 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000028, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jun 23, 2022 at 9:07 AM Michal Hocko wrote: > > On Thu 23-06-22 18:03:31, Vasily Averin wrote: > > Dear Michal, > > do you still have any concerns about this patch set? > > Yes, I do not think we have concluded this to be really necessary. IIRC > Roman would like to see lingering cgroups addressed in not-so-distant > future (http://lkml.kernel.org/r/Ypd2DW7id4M3KJJW@carbon) and we already > have a limit for the number of cgroups in the tree. So why should we > chase after allocations that correspond the cgroups and somehow try to > cap their number via the memory consumption. This looks like something > that will get out of sync eventually and it also doesn't seem like the > best control to me (comparing to an explicit limit to prevent runaways). > -- Let me give a counter argument to that. On a system running multiple workloads, how can the admin come up with a sensible limit for the number of cgroups? There will definitely be jobs that require much more number of sub-cgroups. Asking the admins to dynamically tune another tuneable is just asking for more complications. At the end all the users would just set it to max. I would recommend to see the commit ac7b79fd190b ("inotify, memcg: account inotify instances to kmemcg") where there is already a sysctl (inotify/max_user_instances) to limit the number of instances but there was no sensible way to set that limit on a multi-tenant system.