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 595D0C433EF for ; Fri, 24 Jun 2022 10:40:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F5B08E0210; Fri, 24 Jun 2022 06:40:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A6008E020E; Fri, 24 Jun 2022 06:40:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 86D978E0210; Fri, 24 Jun 2022 06:40:18 -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 742A78E020E for ; Fri, 24 Jun 2022 06:40:18 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 3B673367 for ; Fri, 24 Jun 2022 10:40:18 +0000 (UTC) X-FDA: 79612784916.26.D7F4740 Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) by imf02.hostedemail.com (Postfix) with ESMTP id 790888002F for ; Fri, 24 Jun 2022 10:40:17 +0000 (UTC) Received: by mail-lf1-f51.google.com with SMTP id j21so3793488lfe.1 for ; Fri, 24 Jun 2022 03:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openvz-org.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=AJmnLzRfv3CKjpAFSm8w5uUX4zkxlzpS9NJDok/nCk8=; b=7HedpVdtZRLHDg268+oLo/eUh38UD497b1xuP0kyTrOApUY9ey+kT8c0TnmBPY+t9U mL3HMOpxmxQIYWukMfePC89vZe9yHBTYZIR98SC8JnF5PNc4ICv87ZpVlu0TxWY8d45R d9z0Mgc5yU0iDhbJBhLbs8Baz9W25uKdFESjuRdahXy0c+L74oYBwxW/vkQdtCl/Zp2b o7Ofb3Rb/6lKL6zcj87m09gmw0mAbgTtb4y8Hd8FQfwViCQZAfDmOdf8Vt7L2w/ctbFt osjhl7TXYXzxDD/VddKOpv5+aF5y9/2rtyKZkQcDfn86chNYao3fOf/kYoH3POPiDcmI cuLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=AJmnLzRfv3CKjpAFSm8w5uUX4zkxlzpS9NJDok/nCk8=; b=Q1Vrw3L2FQWjUaInhXUyq/1vAMP4cf2sb0I0FAjVKbjy4jMfyx8V7NrxLRooeR8Grq 1X0XcFOIK1OYT0kYlHroPfFgtPBWud5hVu+08kggJGtTpM62rga7Z+E2nRMWb1zZVy+Z fUgEyADoY8vQfQNj7mgtU5jzh/ip0K7RE0CS3p34nIfIGnu7/AVOQGUjlIkGU8t0BUEi LlPvOuPYsV/itr2IN6OYjExDiO60imPJLrjB9goeGAA7ocXDDxsLqSnPMkNRtdIAKvan KDLeNRsVHwobfU8e8Y+TXcaLUHI4BQKP9Ql5o40g0rQMecLLfQ00zYmGJ01ovGfHkqCr BOOQ== X-Gm-Message-State: AJIora8ky4Ve5uQtEyfdmp2MwvD9gQV/XluPCAAv+7vydsZMh1xcfA7s MoaVRMSpkP8ZtorYviq8URYOnw== X-Google-Smtp-Source: AGRyM1spY9eC2EEhD934ao3bTtj+9AIG31KaKJxVQ5yli2D+p9LF1XUzqtEEzlNZUQyOCZEGB0y6hQ== X-Received: by 2002:a19:dc0f:0:b0:47f:1b37:8d8a with SMTP id t15-20020a19dc0f000000b0047f1b378d8amr8422183lfg.12.1656067215555; Fri, 24 Jun 2022 03:40:15 -0700 (PDT) Received: from [192.168.1.65] ([46.188.121.129]) by smtp.gmail.com with ESMTPSA id bq26-20020a056512151a00b0047976e7388bsm311119lfb.81.2022.06.24.03.40.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Jun 2022 03:40:15 -0700 (PDT) Message-ID: <0f8146e3-5865-b7e6-6728-5baada375cf2@openvz.org> Date: Fri, 24 Jun 2022 13:40:14 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH mm v5 0/9] memcg: accounting for objects allocated by mkdir, cgroup Content-Language: en-US To: Shakeel Butt , Michal Hocko Cc: kernel@openvz.org, Andrew Morton , LKML , Linux MM , Roman Gushchin , =?UTF-8?Q?Michal_Koutn=c3=bd?= , Vlastimil Babka , Muchun Song , Cgroups References: <4e685057-b07d-745d-fdaa-1a6a5a681060@openvz.org> <0fe836b4-5c0f-0e32-d511-db816d359748@openvz.org> From: Vasily Averin In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656067217; a=rsa-sha256; cv=none; b=oYKQ0GXMIlEAcc66cKl/512HNpakIrnlULlcY8EoU0WHO5LqF5DSqW9evMMimxCF0I1oF7 HgcT6G0+1cdJZUQ1fHau0GzSXdaIEVfQOf34bN+EQKI1Ncv6jiHKRWlnqBoopCLhBrNe+c 6SVKMbSSWQ1SsJTNg0DvoU/G6M2rDVU= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=openvz-org.20210112.gappssmtp.com header.s=20210112 header.b=7HedpVdt; spf=pass (imf02.hostedemail.com: domain of vvs@openvz.org designates 209.85.167.51 as permitted sender) smtp.mailfrom=vvs@openvz.org; dmarc=pass (policy=none) header.from=openvz.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656067217; 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=AJmnLzRfv3CKjpAFSm8w5uUX4zkxlzpS9NJDok/nCk8=; b=gkWGaHxCgZ5QsHwgHdzjRDZ9Ai/LD2fX1pXQVL6k4StsQXfwVLVMxBU2sUWwGT3TSo2bHg OoImuitofTc2ZlnUcMX5PitV4YUc/vZ4NKJhOHTqoZ4B/6OSqyPHkXpUhqsAMMFizZ8pqZ nJGTI2TIzLChBZYdq1CB+zfjkoiFUss= X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 790888002F Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=openvz-org.20210112.gappssmtp.com header.s=20210112 header.b=7HedpVdt; spf=pass (imf02.hostedemail.com: domain of vvs@openvz.org designates 209.85.167.51 as permitted sender) smtp.mailfrom=vvs@openvz.org; dmarc=pass (policy=none) header.from=openvz.org X-Rspam-User: X-Stat-Signature: xru86oqfn5u7gno1qkcfyx76km6ddjpp X-HE-Tag: 1656067217-670914 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: On 6/23/22 19:55, 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? 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. I've found that MEM_CGROUP_ID_MAX limits memory cgroups only. Other types of cgroups do not have similar restrictions. Yes, we can set some per-container limit for all cgroups, but to me it looks like workaround while proper memory accounting looks like real solution. Btw could you please explain why memory cgroups have MEM_CGROUP_ID_MAX limit Why it is required at all and why it was set to USHRT_MAX? I believe that in the future it may be really reachable: Let's set up per-container cgroup limit to some small numbers, for example to 512 as OpenVz doing right now. On real node with 300 containers we can easily get 100*300 = 30000 cgroups, and consume ~3Gb memory, without any misuse. I think it is too much to ignore its accounting. Thank you, Vasily Averin