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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A0CEC433FE for ; Wed, 27 Apr 2022 22:22:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231990AbiD0WZS (ORCPT ); Wed, 27 Apr 2022 18:25:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41972 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232043AbiD0WZO (ORCPT ); Wed, 27 Apr 2022 18:25:14 -0400 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 39ED62AE19 for ; Wed, 27 Apr 2022 15:22:00 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id y3so5996469ejo.12 for ; Wed, 27 Apr 2022 15:22:00 -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=oLug1+azcE2h7QMeDbpYAnTwrafPSTpRFVPk0zNJveg=; b=zI/nSf1n1K3Do1i5nBCb7lwViY+DJKmUvfVcoGHl/Q5SvQj83PNn1mVYoRuClPrpw9 sCkAImuE2tFKtQFVPcYA9jGml9m/Bwy/ymA5Te4m1zi4dRCXKacQNmNJgYeS0VEfkWbh FvpiNqvdCThOvFYOiROhJZSsBkCxP0ox1W6C1im3DrClwe4LGTwoTkmKjqIyNiDE7bF0 IWrLpdiZfx31n46ZBikenK9K101cENCfFgSuYqLOkJ+QkFHBJEC++7GoEDz9r43mo8AA LxJWR0R9yV0SBiYBa/bFhSnWkwE1pEHgs0W4l9FVYG8LeYNpO4bMEe33NvulIrzx7+7e S/ew== 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=oLug1+azcE2h7QMeDbpYAnTwrafPSTpRFVPk0zNJveg=; b=1vlm2r18JoAyCNA3TYQ6LDP+OhL7r8xjpTX8B5V0Hs9TvBpBr2CH4t2yNwXSCOvxsp oJHUgSA9Cm9aDrLsNi0vUsDQV/HmPTod8C5xxwpn2YgXUAKp3XTFcU8uo9qHSbpp0kmk txH5xH7lOZnkBrjr0xVoaV+yWy1sGdpEKrD1vHnFz+gjNsVxZ2C6y5L8g5BybILTtfow l4EoA1JO6Pxm7rkliVkG4nkqMJTfunCkTYVoMewmyS8/0hmp0HJYtwlN2BwqSAjbUlVX JuflzcbQff9i/Jp1XASKs+59TQ5CiP8N8YGmbUktKjiLrVlPkRcAyzJ1cWtSfHkPWbYj 8JHA== X-Gm-Message-State: AOAM533Xr7cDgvr4gx6FtXfkLF9OCMJ3NxpYB7q0Xh36f5Jcnb/4C4BQ RIqSlnBiG5bqY471fsH3c0ykQLizCngtfRrD X-Google-Smtp-Source: ABdhPJz1TeiDRK9Dtg2V4JeedZUcQpLNTqRFf/nLyars8/MHGhWw+9q7854+9snyo0BcYh5sVqbLYg== X-Received: by 2002:a2e:a593:0:b0:24d:b9a6:b85c with SMTP id m19-20020a2ea593000000b0024db9a6b85cmr5137954ljp.309.1651097815894; Wed, 27 Apr 2022 15:16:55 -0700 (PDT) Received: from [192.168.1.65] ([46.188.121.177]) by smtp.gmail.com with ESMTPSA id a5-20020a2e9805000000b0024f12f0eb37sm999061ljj.95.2022.04.27.15.16.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Apr 2022 15:16:55 -0700 (PDT) Message-ID: <6b18f82d-1950-b38e-f3f5-94f6c23f0edb@openvz.org> Date: Thu, 28 Apr 2022 01:16:53 +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: [PATCH memcg v4] net: set proper memcg for net_init hooks allocations Content-Language: en-US To: Shakeel Butt , =?UTF-8?Q?Michal_Koutn=c3=bd?= Cc: Vlastimil Babka , Roman Gushchin , kernel@openvz.org, Florian Westphal , LKML , Michal Hocko , Cgroups , netdev , "David S. Miller" , Jakub Kicinski , Paolo Abeni References: <33085523-a8b9-1bf6-2726-f456f59015ef@openvz.org> <20220427122232.GA9823@blackbody.suse.cz> From: Vasily Averin In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/27/22 18:06, Shakeel Butt wrote: > On Wed, Apr 27, 2022 at 5:22 AM Michal Koutný wrote: >> >> On Tue, Apr 26, 2022 at 10:23:32PM -0700, Shakeel Butt wrote: >>> [...] >>>> >>>> +static inline struct mem_cgroup *get_mem_cgroup_from_obj(void *p) >>>> +{ >>>> + struct mem_cgroup *memcg; >>>> + >>> >>> Do we need memcg_kmem_enabled() check here or maybe >>> mem_cgroup_from_obj() should be doing memcg_kmem_enabled() instead of >>> mem_cgroup_disabled() as we can have "cgroup.memory=nokmem" boot >>> param. Shakeel, unfortunately I'm not ready to answer this question right now. I even did not noticed that memcg_kmem_enabled() and mem_cgroup_disabled() have a different nature. If you have no objections I'm going to keep this place as is and investigate this question later. >> I reckon such a guard is on the charge side and readers should treat >> NULL and root_mem_group equally. Or is there a case when these two are >> different? >> >> (I can see it's different semantics when stored in current->active_memcg >> (and active_memcg() getter) but for such "outer" callers like here it >> seems equal.) Dear Michal, I may have misunderstood your point of view, so let me explain my vision in more detail. I do not think that NULL and root_mem_cgroup are equal here: - we have enabled cgroups and well-defined root_mem_cgroup, - this function is called from inside memcg-limited container, - we tried to get memcg from net, but without success, and as result got NULL from mem_cgroup_from_obj() (frankly speaking I do not think this situation is really possible) If we keep memcg = NULL, then current's memcg will not be masked and net_init's allocations will be accounted to current's memcg. So we need to set active_memcg to root_mem_cgroup, it helps to avoid incorrect accounting. > I was more thinking about possible shortcut optimization and unrelated > to this patch. > > Vasily, can you please add documentation for get_mem_cgroup_from_obj() > similar to get_mem_cgroup_from_mm()? Also for mem_cgroup_or_root(). > Please note that root_mem_cgroup can be NULL during early boot. Ok, thank you for the remark, I'll improve it in next patch version. Thank you, Vasily Averin