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 47EE3C433EF for ; Tue, 12 Jul 2022 16:24:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A98139400A4; Tue, 12 Jul 2022 12:24:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A47EC940063; Tue, 12 Jul 2022 12:24:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 90FB89400A4; Tue, 12 Jul 2022 12:24:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 817FE940063 for ; Tue, 12 Jul 2022 12:24:24 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 471FB60541 for ; Tue, 12 Jul 2022 16:24:24 +0000 (UTC) X-FDA: 79678970448.03.182143B Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) by imf07.hostedemail.com (Postfix) with ESMTP id DFC6B4003B for ; Tue, 12 Jul 2022 16:24:23 +0000 (UTC) Received: by mail-pj1-f45.google.com with SMTP id a15so8191791pjs.0 for ; Tue, 12 Jul 2022 09:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=7sEHZnwDHngZ8PkrUxm/ATIo3aq5UKj0LAY0nMBz/yk=; b=meJQ/dKf8HP6vS20zVKapOxrcORiVKzXMeR0qkrRs/dGuhkKecJaRK6r2Iss9H2K2j gA5Rzq4tqzIgi5NGmZUm8OyerBZnQZxXA7i5AWTSMU7BP+IOP6RITSysiX1+GtSibOpr InGYEdDZViTnBqcEj9HgVOcmo3T9o+0IFmi1CH2C+Ci+znLIvofR+Kd2RDshqo58PJff aXv/DPcAVZ3x7X+27pEziAPi3yIxwI8mTdNR/WDAvu98ogUyKF8iutbuBO1KwxbqKrRp 3U6Vfx+iImOsbz76hKnyYLmh/Kv1bp08Coae9qoybh1lk8OgcSVY0kOb2uDZbar9du7u HJqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=7sEHZnwDHngZ8PkrUxm/ATIo3aq5UKj0LAY0nMBz/yk=; b=jdwXWbjz4j4bbl/twrLDGkP3ntb5x9koqPHoUuGtvVmFJC0I70nFXiXQS8EWfkCYJX do5BOCQkeQunIlYKVSFEyBtc/CYBOXpOpwaR4YeZjwijWx9BXQGDkkdARQ3EytEKEcgX 0Nfm/sTEECm4gKxQhC4rQ6JPauBLYD8mBQZ8MFQUDSsYPe4QTfBiZX0NK/aHd938mxUw 5mZZgtRZwHt0jQZl4wkDXgz3u7HFrXPnAWl9B6QUnAxPdMFYrl24eyui4jueYFUd2xy0 3HtXhM4HRVH/Vr5zvSqc6V5sZFtqBEFPjFUkL4sGhCg5twscyi9ukSQEGn78pbnysDmJ JXmw== X-Gm-Message-State: AJIora9FVHKwfMTTw63mTLL8T4eMBAF0iN1kI/NDVpqoRp97+rNzhSob T5q5eRSulMr3PHlVuhPtEWg= X-Google-Smtp-Source: AGRyM1vPQIv97fm/20hxzm1gicPKu76SuIxxULA29ZAmF4uFJB7irtvGCWOL90Qd5lx0F5BGLLZvWA== X-Received: by 2002:a17:90b:1e4d:b0:1f0:462b:b573 with SMTP id pi13-20020a17090b1e4d00b001f0462bb573mr5337524pjb.164.1657643062744; Tue, 12 Jul 2022 09:24:22 -0700 (PDT) Received: from localhost (2603-800c-1a02-1bae-a7fa-157f-969a-4cde.res6.spectrum.com. [2603:800c:1a02:1bae:a7fa:157f:969a:4cde]) by smtp.gmail.com with ESMTPSA id be4-20020a656e44000000b0040caab35e5bsm6313952pgb.89.2022.07.12.09.24.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Jul 2022 09:24:21 -0700 (PDT) Date: Tue, 12 Jul 2022 06:24:20 -1000 From: Tejun Heo To: Michal Hocko 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=1657643064; a=rsa-sha256; cv=none; b=dkWASXDepLPNi6lqUwx5uK5eCy1uc3hZaraNl5WCRXhNP+Gj1/59pAFPOIYm7kAolH+LKl d7/klC1isTp3hj8ESbb5nm59rZuzo6Cjroe5r5j3dVb25+yTRTeQKvFofqlsYXlzPERCCN wp35Ne0Q+VsTOhyfufrm34WmuS78IeM= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="meJQ/dKf"; spf=pass (imf07.hostedemail.com: domain of htejun@gmail.com designates 209.85.216.45 as permitted sender) smtp.mailfrom=htejun@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657643064; h=from:from:sender: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=7sEHZnwDHngZ8PkrUxm/ATIo3aq5UKj0LAY0nMBz/yk=; b=KJFtTmHdetL3LHHPqYbN/+vXTv9ekSworveTGUggXv1AAIufUdv0QjADolzb7UIdDxDmjY 2sOPSsZoAPrFM3T4LRwCIIUnG71BJNjJTfbFgWqJJYSEhDhsBUKH0vAXYyyIW2vWVi0Qhe 4iQoal8QCyG+2Y2rYf8NrHQOr5ObURo= X-Rspamd-Queue-Id: DFC6B4003B Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="meJQ/dKf"; spf=pass (imf07.hostedemail.com: domain of htejun@gmail.com designates 209.85.216.45 as permitted sender) smtp.mailfrom=htejun@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) X-Rspamd-Server: rspam02 X-Rspam-User: X-Stat-Signature: 8fpenedz6at6bmfcc1bh5wnp7ytny8k4 X-HE-Tag: 1657643063-884701 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: 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. 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. Thanks. -- tejun