Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1485301iob; Thu, 5 May 2022 02:21:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwCM0W36OINBaUuBFVS0iuB7aHijDrkip76PzTlbeYFqiCF3K6UiQa0GG0A9hFUKnsRm2bZ X-Received: by 2002:a17:903:1249:b0:15e:8b15:b7d2 with SMTP id u9-20020a170903124900b0015e8b15b7d2mr27662350plh.150.1651742510481; Thu, 05 May 2022 02:21:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651742510; cv=none; d=google.com; s=arc-20160816; b=yh4abno2JcnP4u+uojP1mUcsZb5N4t8PmdYg+/Q82hISGQF53qp+WIShlv9O/XqNmW qGK/TxD6G4TXpeOJ2ZZNIW+/HyLbn/sjbi04hr9YfPeanX2TAHMrJSqU3D5dJOatQQoy c7DSljrfPJKQsVcic5VNEkMBHzRaf2g7AnuMlmNzBO3WpKllO6KMh7IMs7ir7ZqMcRAF nHYSeHl67lslt53CSpVGOJMAY4hiES6OVwQrdPUS2D8mhxTW+T4c9VqX5NMfb/qaPYSi ZtG47Buyt86JSAyDfou+HSI4ndvGNRv/FfDoz2zVhyJOUKhptH65N6/tyYC+exWFKdYJ u7sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=tdFt0uQlPJ4mzIwCT11tWacBOCFR/O+DCJD9m2elhvY=; b=YsHHv232lvcjSuNj+IA1xm5f3Hmu2hRW+jGp6BwN0KBEgNbQzkSzNtzpv2N15wxEjW 0IruNCRZZ3S8bIXbT2Tv6aDvLjSmQPFbsUYS6yOGPFJt4+YsW/og/vPuJztKnzhbvC/j +j6osGZ4gZVpT9W6fr40AAmKXWz7qp96kR90Y8/mXZfgaZIGPOSg83GwfNnn8UTAV+Nk M41xsx5+WbsVTO78kcXVZHCr/A56XrtRqougMlUJezjiFSOAeBiVA9XA3127VGgPgNZB Q20JsAOZQKE3+uGEWqr70zjspvReri48TBgjHPNUohVmrwcxVLYLwey7+SUt7BacvdRP 3fIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@openvz-org.20210112.gappssmtp.com header.s=20210112 header.b=4BtgJE6t; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=openvz.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s63-20020a637742000000b003ab0e0a6b62si1010603pgc.803.2022.05.05.02.21.36; Thu, 05 May 2022 02:21:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@openvz-org.20210112.gappssmtp.com header.s=20210112 header.b=4BtgJE6t; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=openvz.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378540AbiEDVT6 (ORCPT + 99 others); Wed, 4 May 2022 17:19:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357423AbiEDVTy (ORCPT ); Wed, 4 May 2022 17:19:54 -0400 Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0CD82220C4 for ; Wed, 4 May 2022 14:16:16 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id 4so3251912ljw.11 for ; Wed, 04 May 2022 14:16:15 -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=tdFt0uQlPJ4mzIwCT11tWacBOCFR/O+DCJD9m2elhvY=; b=4BtgJE6tIVi5spqKRy2safmJJvFhDwqig/gu8SOgJVMNlQoN7e6oyggAGtbh0Ai3u+ mR+n9pawKCECW0w4KaZIWSRlsLDNrXNLicQze8WR7YOF14HoGfcdcRrLoH9tjDGrbzFy WDWbyL2Nu4xZje0kDJ17xDqguvfoDCMUQSyM3hLgoAUlMcGEsTF7qPjnbhKhdYfxmucs wHUTkWv/1+fU/qFlF5OKiFmii/NXaHWgs3XvRrl4Eifnz5ATici85iWc4YhEkszOJAxc Bha+LOrKUOvCCgZ0Q3zYOFb0L/mULFRJtIuA6ZizjW+wmIlKvPAcW/NJrfdYapYD95QF c2mg== 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=tdFt0uQlPJ4mzIwCT11tWacBOCFR/O+DCJD9m2elhvY=; b=4ocEM2cFmuZ+9ka1iXWyJQvvGERQshJYrpmm4tqNKHJkP+Iy1nkL2ihp71QZWN67CY oAjRFkpedZCitZkAuiRFzc9bX1DDOgAvNmmqJ3jSQwaKPy4jQ3h52b0WG96VpU99SFsJ BqECCyQg7GmRiEnDGI7GNKbKlI5Erc+02Aj8Bx2zMUrKNSKaz3x2mzllz3kVmWL3Rgq+ VdAUUJOLlkeOZ9KIJQPbU+5vhd9+PWaSFzVV3ZNfVwtrZ/QyX6t4gDpmFoSiq4wOeK2o pz8u86h+SU39+oQ5LzrEr44BD+p79BMTBDYY64d4NO8ea0F+fvPavsGOBSP8Hef/UvKR JFRA== X-Gm-Message-State: AOAM531N6dhlrUr946vE4vRKW5vunAI6SPBsviMKBY504ciEAho4kHhL TnpDubSTljx1htcWaq3hELfq9g== X-Received: by 2002:a05:651c:10b4:b0:24f:88b:2dc3 with SMTP id k20-20020a05651c10b400b0024f088b2dc3mr13985315ljn.383.1651698974268; Wed, 04 May 2022 14:16:14 -0700 (PDT) Received: from [192.168.1.65] ([46.188.121.177]) by smtp.gmail.com with ESMTPSA id j26-20020a19f51a000000b0047255d21115sm1302266lfb.68.2022.05.04.14.16.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 May 2022 14:16:13 -0700 (PDT) Message-ID: <65244222-02c5-6e8d-7f4b-83651f378ce2@openvz.org> Date: Thu, 5 May 2022 00:16:12 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: kernfs memcg accounting Content-Language: en-US To: =?UTF-8?Q?Michal_Koutn=c3=bd?= Cc: Roman Gushchin , Vlastimil Babka , Shakeel Butt , kernel@openvz.org, Florian Westphal , linux-kernel@vger.kernel.org, Michal Hocko , cgroups@vger.kernel.org, Greg Kroah-Hartman , Tejun Heo References: <7e867cb0-89d6-402c-33d2-9b9ba0ba1523@openvz.org> <20220427140153.GC9823@blackbody.suse.cz> <7509fa9f-9d15-2f29-cb2f-ac0e8d99a948@openvz.org> <52a9f35b-458b-44c4-7fc8-d05c8db0c73f@openvz.org> <20220504141001.GA10890@blackbody.suse.cz> From: Vasily Averin In-Reply-To: <20220504141001.GA10890@blackbody.suse.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/4/22 17:10, Michal Koutný wrote: > On Wed, May 04, 2022 at 12:00:18PM +0300, Vasily Averin wrote: >> As far as I understand, Roman chose the parent memcg because it was a special >> case of creating a new memory group. He temporally changed active memcg >> in mem_cgroup_css_alloc() and properly accounted all required memcg-specific >> allocations. > >> However, he ignored accounting for a rather large struct mem_cgroup >> therefore I think we can do not worry about 128 bytes of kernfs node. > > Are you referring to the current code (>= v5.18-rc2)? All big structs > related to mem_cgroup should be accounted. What is ignored? mm/memcontrol.c: 5079 static struct mem_cgroup *mem_cgroup_alloc(void) 5080 { 5081 struct mem_cgroup *memcg; ... 5086 memcg = kzalloc(struct_size(memcg, nodeinfo, nr_node_ids), GFP_KERNEL); I think it should allocate at least 2 pages. >> Primary I mean here struct mem_cgroup allocation in mem_cgroup_alloc(). > > Just note that memory controller may not be always enabled so > cgroup_mkdir != mem_cgroup_alloc(). However if cgroup_mkdir() calls mem_cgroup_alloc() it correctly account huge percpu allocations but ignores neighbour multipage allocation. >> However, I think we need to take into account any other distributions called >> inside cgroup_mkdir: struct cgroup and kernefs node in common part and >> any other cgroup-cpecific allocations in other .css_alloc functions. >> They all can be called from inside container, allocates non-accountable >> memory and by this way theoretically can be misused. > > Also note that (if you're purely on unified hierachy) you can protect > against that with cgroup.max.descendants and cgroup.max.depth. In past OpenVz had a lot of limits for various resources (for example we had a limit for iptable rules), but it was very hard to configure them properly. Finally we decided to replace all such custom limits by common memory limit. It isn't important how many resources tries to use container as long as it doesn't exceed the memory limit. Such resource limits can be useful, especially to prevent possible misuses. However sooner or later there will be a legal user who will rest against them. All you can do in this situation is to recommend him just increase the limit, that makes the limit senseless. Memory limits looks much more reasonable and understandable. Thank you, Vasily Averin