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 0958DC433EF for ; Mon, 18 Jul 2022 14:13:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 35F556B0072; Mon, 18 Jul 2022 10:13:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 310D06B0073; Mon, 18 Jul 2022 10:13:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D7466B0074; Mon, 18 Jul 2022 10:13:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 0EB286B0072 for ; Mon, 18 Jul 2022 10:13:39 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id CD75A2082E for ; Mon, 18 Jul 2022 14:13:38 +0000 (UTC) X-FDA: 79700413716.21.5E9F40A Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf18.hostedemail.com (Postfix) with ESMTP id E0BCD1C008D for ; Mon, 18 Jul 2022 14:13:37 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id F314533CFA; Mon, 18 Jul 2022 14:13:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1658153616; 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=Op5MBj9BJf4R8av8QSxiYS2XjeRSFgLubMjLAKL6O8k=; b=AODiV9Y1aeA/xOSckULSkAEillhxb1/kpdQtn18FXdbHGL1q6X+Ab/myog4omDJUj/59jz /rMRHLteFbcLsCO3zbbykRMHmEBwYZNo1eIR+lS6f2coA7KtPdKkNHAeldVwkToFrm9DOA 1pfyrsuF1LxLMAJvjXqUhExwGIfd8BE= 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 D910C2C161; Mon, 18 Jul 2022 14:13:31 +0000 (UTC) Date: Mon, 18 Jul 2022 16:13:31 +0200 From: Michal Hocko To: Tejun Heo Cc: Yafang Shao , Alexei Starovoitov , Shakeel Butt , Matthew Wilcox , Christoph Hellwig , "David S. Miller" , Daniel Borkmann , Andrii Nakryiko , 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: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658153618; a=rsa-sha256; cv=none; b=xLg0UBUzD/ciTb9TlSMRXAYyg7iXm6nYFkCtf6tnwm3ZvrcNkI18VUEfGSNy/0xCYcGYXX yNEPNbmfl3OvK64qABM+5fNeyAYp3WOTGD5+G8kKJ7XnjNjx7SVNh/MnvYeJa9CxJxWiJC uy+32x2Y96EzCpiqYlonc5MgswhHbmI= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=AODiV9Y1; 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658153618; 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=Op5MBj9BJf4R8av8QSxiYS2XjeRSFgLubMjLAKL6O8k=; b=7YlmY9HXC6Gx9fNJHq4LLqTa6NqJslDArArdJbq+JrAvlBPZsSg43edPY7ObfYml8kGpQP krKdnY0h4R2U/XipElKWwz7T61Ix3/G0SamHMHyEW4E78930grU//r3dZaAaeHq5Pl7lpJ n9XvL7K3dzSrDqhz4/K9yQvL/UsEPBw= X-Stat-Signature: i9he1cypu3d7un9foof1mgxw1gx3onoe X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: E0BCD1C008D X-Rspam-User: Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=AODiV9Y1; 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-HE-Tag: 1658153617-788066 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 12-07-22 06:24:20, Tejun Heo wrote: > Hello, Michal. > > On Tue, Jul 12, 2022 at 11:52:11AM +0200, Michal Hocko wrote: > > > 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. > > I think the solution here is an extra cgroup layering to represent > persistent resource tracking. In systemd-speak, a service should have a > cgroup representing a persistent service type and a cgroup representing the > current running instance. This way, the user (or system agent) can clearly > distinguish all resources that have ever been attributed to the service and > the resources that are accounted to the current instance while also giving > visibility into residual resources for services that are no longer running. Just to make sure I follow what you mean here. You are suggesting that the cgroup manager would ensure that there will be a parent responsible for the resource and that cgroup will not go away as long as there are resources (well modulo admin interferese which is not really interesting usecase). I do agree that this approach would be easier from the kernel perspective. It is also more error prone because some resources might be so runtime specific that it is hard to predict and configure them in advance. My thinking about "sticky" cgroups was based on the reference count of approach when the kernel knows that the resource requires some sort of tear down which is not process life scoped and would take a reference on the cgroup to keep it alive. I can see a concern that this can get quite subtle in many cases though. > This gives userspace control over what to track for how long and also fits > what the kernel can do in terms of resource tracking. If we try to do > something smart from kernel side, there are cases which are inherently > insolvable. e.g. if a service instance creates tmpfs / shmem / whawtever and > leaves it pinned one way or another and then exits, and there's no one who > actively accessed it afterwards, there is no userland visible entity we can > reasonably attribute that memory to other than the parent cgroup. yeah, tmpfs would be another example which is even more complex because a single file can "belong" to different memcgs. -- Michal Hocko SUSE Labs