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 9BCD4C43334 for ; Wed, 13 Jul 2022 02:39:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C463E9400F7; Tue, 12 Jul 2022 22:39:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BF63D9400E5; Tue, 12 Jul 2022 22:39:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AE4939400F7; Tue, 12 Jul 2022 22:39:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9F0329400E5 for ; Tue, 12 Jul 2022 22:39:12 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 66FB43495C for ; Wed, 13 Jul 2022 02:39:12 +0000 (UTC) X-FDA: 79680519744.24.12EFACB Received: from out2.migadu.com (out2.migadu.com [188.165.223.204]) by imf20.hostedemail.com (Postfix) with ESMTP id 7E38C1C009D for ; Wed, 13 Jul 2022 02:39:11 +0000 (UTC) Date: Tue, 12 Jul 2022 19:39:02 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1657679950; h=from:from:reply-to:subject:subject: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=Zf80XZEaZtqk7AVq5EEeCqFQwvbUG56hYMzo/FstPo0=; b=qRlUM/ob500PR9fOwc5P/Ti8NN+557hQQZo+tWCi3BYGOPrxowmdXFY2ksfTiMfcfaXQoe OX6Y5QRzl/xVgv463nZsGdpTqvF+GmyrQSFGNbqnupqRc4agp6ADleT7YaKNaF0E9OP++q k+S1ORW0w9pyHKzz+5g4bNl+Mxpb6rE= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Michal Hocko Cc: Yafang Shao , 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: <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: X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657679951; a=rsa-sha256; cv=none; b=r2Ka5ihc26Ba8bwyGBemmgP3ccI4ccZ7BsuXJpQvm7dLHcU9rVmSVdciba4WWPc597Ij80 jQXDy8jfUgBjtPvxBqjtWnjm2ThPw876D2KbzlIbdLduBZjRyTBxWMyxge5ejS5m76pWyI qlARRseinGjMHlK856YQW/j1OHRQzeQ= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="qRlUM/ob"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf20.hostedemail.com: domain of roman.gushchin@linux.dev designates 188.165.223.204 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657679951; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Zf80XZEaZtqk7AVq5EEeCqFQwvbUG56hYMzo/FstPo0=; b=PnzkMK+sA/tPcqD07gi3QgmuWkYlqpQ/59X7JB60vsXqTfIqCixM/ko2LzaF4In6BsLMYs RxRcwL/v3GtfEARAoHkkU6K/8nHC3zlwBi8mDcxpznzW7u5GbjkPWs1kHgHPKtlPdgTr1D weEPM6nPQ5igRuFigGOQBdAczBqPDtQ= X-Rspam-User: X-Stat-Signature: zpmbq6kjbr71asmopgf66xrgcr41dnxw X-Rspamd-Queue-Id: 7E38C1C009D Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="qRlUM/ob"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf20.hostedemail.com: domain of roman.gushchin@linux.dev designates 188.165.223.204 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev X-Rspamd-Server: rspam03 X-HE-Tag: 1657679951-476172 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 Tue, Jul 12, 2022 at 11:52:11AM +0200, Michal Hocko wrote: > 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. I agree, I also don't like reparenting for !kmem case. For kmem (and *maybe* bpf maps is an exception), I don't think there is a better choice. > 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. Well, then we have to make these objects a first-class citizens in cgroup API, like processes. E.g. introduce cgroup.bpf.maps, cgroup.mounts.tmpfs etc. I easily can see some value here, but it's a big API change. With the current approach when a bpf map pins a memory cgroup of the creator process (which I think is completely transparent for most bpf users), I don't think preventing the deletion of a such cgroup is possible. It will break too many things. But honestly I don't see why userspace can't handle it. If there is a cgroup which contains shared bpf maps, why would it delete it? It's a weird use case, I don't think we have to optimize for it. Also, we do a ton of optimizations for live cgroups (e.g. css refcounting being percpu) which are not working for a deleted cgroup. So noone really should expect any properties from dying cgroups. Thanks!