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 5C518CCA47C for ; Tue, 12 Jul 2022 09:52:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232324AbiGLJwR (ORCPT ); Tue, 12 Jul 2022 05:52:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42754 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232294AbiGLJwQ (ORCPT ); Tue, 12 Jul 2022 05:52:16 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 82077AA80B for ; Tue, 12 Jul 2022 02:52:15 -0700 (PDT) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 375761F96B; Tue, 12 Jul 2022 09:52:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1657619534; 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=pm4VPHZ7hwTErGyoQgCSf/HU8qiZ3Mug86BUwr6Vsew=; b=Mh1Wn8yFVQcQ5nJ4E8dYkxnDW/OGEJV0bjE14MV8rW2DkKs5Dha8eWapckuaPZwK+scDOk fzguBpWnXmFXX8bv+X7th5QqVZuZ300e3+CDugbhBDuw6PPxqdFB4CPmpp1Qx2Inroht0T NWJOeGay1zVpHKaekvL3B3CrAkEtLUw= 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 F351C2C141; Tue, 12 Jul 2022 09:52:11 +0000 (UTC) Date: Tue, 12 Jul 2022 11:52:11 +0200 From: Michal Hocko To: Yafang Shao Cc: Alexei Starovoitov , Shakeel Butt , Matthew Wilcox , Christoph Hellwig , "David S. Miller" , Daniel Borkmann , Andrii Nakryiko , Tejun Heo , Martin KaFai Lau , bpf , Kernel Team , linux-mm , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka Subject: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator. Message-ID: References: <20220706180525.ozkxnbifgd4vzxym@MacBook-Pro-3.local.dhcp.thefacebook.com> <20220708174858.6gl2ag3asmoimpoe@macbook-pro-3.dhcp.thefacebook.com> <20220708215536.pqclxdqvtrfll2y4@google.com> <20220710073213.bkkdweiqrlnr35sv@google.com> <20220712043914.pxmbm7vockuvpmmh@macbook-pro-3.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Tue 12-07-22 16:39:48, Yafang Shao wrote: > On Tue, Jul 12, 2022 at 3:40 PM Michal Hocko wrote: [...] > > > Roman already sent reparenting fix: > > > https://patchwork.kernel.org/project/netdevbpf/patch/20220711162827.184743-1-roman.gushchin@linux.dev/ > > > > Reparenting is nice but not a silver bullet. Consider a shallow > > hierarchy where the charging happens in the first level under the root > > memcg. Reparenting to the root is just pushing everything under the > > system resources category. > > > > Agreed. That's why I don't like reparenting. > Reparenting just reparent the charged pages and then redirect the new > charge, but can't reparents the 'limit' of the original memcg. > So it is a risk if the original memcg is still being charged. We have > to forbid the destruction of the original memcg. yes, I was toying with an idea like that. I guess we really want a measure to keep cgroups around if they are bound to a resource which is sticky itself. I am not sure how many other resources like BPF (aka module like) we already do charge for memcg but considering the potential memory consumption just reparenting will not help in general case I am afraid. -- Michal Hocko SUSE Labs