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 34BB4C433F5 for ; Wed, 1 Jun 2022 09:27:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A089F6B009D; Wed, 1 Jun 2022 05:26:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B7D16B009F; Wed, 1 Jun 2022 05:26:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 87B816B00A0; Wed, 1 Jun 2022 05:26:59 -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 7AB906B009D for ; Wed, 1 Jun 2022 05:26:59 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 533BB20961 for ; Wed, 1 Jun 2022 09:26:59 +0000 (UTC) X-FDA: 79529137758.28.D248540 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf18.hostedemail.com (Postfix) with ESMTP id B79601C0044 for ; Wed, 1 Jun 2022 09:26:38 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 6F21121A8A; Wed, 1 Jun 2022 09:26:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1654075617; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=umyJ259eqDO/AWl48+5+ukfsnKPvszoN7+zzaQVPwm8=; b=WoreISCAqGglNQ8BJCy9DimpyyoJ5TmjQXs5xFqaChdfvvjWTEM/Z/C/9xylNwI8JCAecl dlXZ3yxKbq25Ub4V0OGKQ6Jw0yolmXWFO7VolBdU29hcv+0VkSMqBfc1HQQ4fU0y3OB2+j eO7TltYUvtkJnEhhoEHEbHPVjSWSSkU= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 07A812C141; Wed, 1 Jun 2022 09:26:55 +0000 (UTC) Date: Wed, 1 Jun 2022 11:26:55 +0200 From: Michal Hocko To: Vasily Averin Cc: Andrew Morton , kernel@openvz.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Shakeel Butt , Roman Gushchin , Michal =?iso-8859-1?Q?Koutn=FD?= , Vlastimil Babka , Muchun Song , cgroups@vger.kernel.org Subject: Re: [PATCH mm v3 0/9] memcg: accounting for objects allocated by mkdir cgroup Message-ID: References: <06505918-3b8a-0ad5-5951-89ecb510138e@openvz.org> <3e1d6eab-57c7-ba3d-67e1-c45aa0dfa2ab@openvz.org> <3a1d8554-755f-7976-1e00-a0e7fb62c86e@openvz.org> <118bcb39-1281-0d1d-b163-3f6bcc99c3e2@openvz.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <118bcb39-1281-0d1d-b163-3f6bcc99c3e2@openvz.org> X-Stat-Signature: c4inxdox64zuw5jgo3zkbhfurt7efpc8 X-Rspam-User: Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=WoreISCA; spf=pass (imf18.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: B79601C0044 X-HE-Tag: 1654075598-340324 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 Wed 01-06-22 06:43:27, Vasily Averin wrote: [...] > However, it isn't critical for OpenVz. Our kernel does not allow > to change of cgroup.subgroups_limit from inside containers. What is the semantic of this limit? > CT-901 /# cat /sys/fs/cgroup/memory/cgroup.subgroups_limit > 512 > CT-901 /# echo 3333 > /sys/fs/cgroup/memory/cgroup.subgroups_limit > -bash: echo: write error: Operation not permitted > CT-901 /# echo 333 > /sys/fs/cgroup/memory/cgroup.subgroups_limit > -bash: echo: write error: Operation not permitted > > I doubt this way can be accepted in upstream, however for OpenVz > something like this it is mandatory because it much better > than nothing. > > The number can be adjusted by host admin. The current default limit > looks too small for me, however it is not difficult to increase it > to a reasonable 10,000. > > My experiments show that ~10000 cgroups consumes 0.5 Gb memory on 4cpu VM. > On "big irons" it can easily grow up to several Gb. This is quite a lot > to ignore its accounting. Too many cgroups can certainly have a high memory footprint. I guess this is quite clear. The question is whether trying to limit them by the memory footprint is really the right way to go. I would be especially worried about those smaller machines because of a smaller footprint which would allow to deplete the id space faster. Maybe we need some sort of limit on the number of cgroups in a subtree so that any potential runaway can be prevented regardless of the cgroups memory footprint. One potentially big problem with that is that cgroups can live quite long after being offlined (e.g. memcg) so such a limit could easily trigger I can imagine. -- Michal Hocko SUSE Labs