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 7D697C43334 for ; Mon, 27 Jun 2022 16:37:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 164888E0002; Mon, 27 Jun 2022 12:37:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1152F8E0001; Mon, 27 Jun 2022 12:37:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F1FB98E0002; Mon, 27 Jun 2022 12:37:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id E605F8E0001 for ; Mon, 27 Jun 2022 12:37:26 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C2682604FD for ; Mon, 27 Jun 2022 16:37:26 +0000 (UTC) X-FDA: 79624571292.21.DB2C8EB Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by imf03.hostedemail.com (Postfix) with ESMTP id 69D462001C for ; Mon, 27 Jun 2022 16:37:26 +0000 (UTC) Received: by mail-yb1-f181.google.com with SMTP id h187so15484345ybg.0 for ; Mon, 27 Jun 2022 09:37:26 -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=M2vRONC13amhSE1W+iisI+raE+PvPU52ESA4pnszZg8=; b=UEcpkmCqZthqdDmCcJb/GHcW0WYvQnSCthVpaKsdmJhtGXLqN7CSupnYP/T9EPiFCT dpWNdyhfR++Q5OkhmkqsGWC8xP+zsLjqe1hZEPiTRDPwzXUixzZdYN+OrQiKxHD6+YND syqoKAJUsXT0A6UFFYH6qKrCaYiRvAEakeCdLDH8ogsyCp24jeLat9pAf8A3f5Kaa916 Ne+P4JzkAkzuD8jViCtMZRJ9dzBpqQSf0OwuZA8SljXz57Vy4S+6COF26L6Jk7HDX7m7 cflaOdwbvTx9eRoOi8K6EYa7WK7WZCXi9s387y7i3owFFtCUK9XdXU/EVohHplY0b3pr tt2w== 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=M2vRONC13amhSE1W+iisI+raE+PvPU52ESA4pnszZg8=; b=qZC/sHRasvzF+PTArKCaMJ8FzuTBTXpkZGC7Y5bceSF41mQPryJkUWSF6VHIGhAxLr 50RxWueoOgdaVyoFSf1ZzcTWZS+QMwmr87BzOQhIYHvOY5fYHqMHOudol56lXgkWDnJ1 huUvITVefLVy1X9FI397cTA8IE/tdsXIqhJw7hloZe5FctxNYXNpr6U6goWiwqdXmIs0 f8ms74yFgIG51VMpiWzhsI/VR55eKNsqYXFqIU7s7qd+sDz62L0Fu6iiKZgWNyKOXtDy PQDGwYqgh2DCtRNNy9uIUK4qo4bih6MKVxp+haZPqYJAT1Izg0bzQpezBwByRJVQwdDE seOA== X-Gm-Message-State: AJIora8BUnIB5VE40OWqRKqywt9YdzIl90rBHkbr0RU7q+JaU9ey7uM5 dnkqFXG9lDRbaj5+y+YcoShFkpJ+z3IV/s6BiSsHutHFPvc= X-Google-Smtp-Source: AGRyM1sTPM7jj4zDy93zPEKtxPXKrzDkCiWDP4UO0S1kmWgyzlhK983F6Y8r4ItcgcZqCrhSji4lQVe3yDiErQ+njmI= X-Received: by 2002:a25:83cf:0:b0:66b:c7e5:faf with SMTP id v15-20020a2583cf000000b0066bc7e50fafmr14517036ybm.288.1656347845647; Mon, 27 Jun 2022 09:37:25 -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: Mon, 27 Jun 2022 09:37:14 -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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656347846; 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=M2vRONC13amhSE1W+iisI+raE+PvPU52ESA4pnszZg8=; b=vuMbDxviizWGip/GnUhhQQShDPLU1phyJvWc1fwJbT8MxT+Se6YVVT1engtuXH3TWB8XHf I2LlmPKs4q/Y6IC920t6N923QzFR1TUzdhFOXQAu1yqgwelQUIFTv7zanmENakvuo5pqAq r23+guoAJ0NE3LwSVg7r0Ey2BMMD70s= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=UEcpkmCq; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of shakeelb@google.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=shakeelb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656347846; a=rsa-sha256; cv=none; b=anzmTJZ4BeSRWbiKVbegPeEw16jEpiVjoLKcO+alQ5kLdxfEk955w7ZDNQITigXWKa5+IC v8CpVryGONhMlypl3TRggbUrXKiSIsPhnzLTmeKtTuXnI7In/tKnioG2FHPszb0JSG2k4/ +6XcUk85I2YR4rjLjv0/mzKsFVy2Av0= X-Rspamd-Queue-Id: 69D462001C Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=UEcpkmCq; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of shakeelb@google.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=shakeelb@google.com X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: fmnbqyy39f3hm1gqo8qkbmjn9x588ofk X-HE-Tag: 1656347846-986009 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000842, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Jun 24, 2022 at 6:59 AM Michal Hocko wrote: > > On Thu 23-06-22 09:55:33, Shakeel Butt wrote: > > 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? > > How is that any easier through memory consumption? Something that might > change between kernel versions? In v2, we do provide a way for admins to right size the containers without killing them. Actually we are trying to use memory.high for right sizing the jobs. (It is not the best but workable and there are opportunities to improve it). Similar mechanisms for other types of limits are lacking. Usually the application would be getting the error for which it can not do anything most of the time. > Is it even possible to prevent from id > depletion by the memory consumption? Any medium sized memcg can easily > consume all the ids AFAICS. Though the patch series is pitched as protection against OOMs, I think it is beneficial irrespective. Protection against an adversarial actor should not be the aim here. IMO this patch series improves the memory association to the actual user which is better than unattributed memory treated as system overhead.