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 54B64C433EF for ; Tue, 12 Jul 2022 15:25:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9231694009D; Tue, 12 Jul 2022 11:25:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8D1BA940063; Tue, 12 Jul 2022 11:25:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 79AB194009D; Tue, 12 Jul 2022 11:25:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 6AAB0940063 for ; Tue, 12 Jul 2022 11:25:39 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 3F0BFEB3 for ; Tue, 12 Jul 2022 15:25:39 +0000 (UTC) X-FDA: 79678822398.24.3BC8691 Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by imf10.hostedemail.com (Postfix) with ESMTP id 26763C009B for ; Tue, 12 Jul 2022 15:25:36 +0000 (UTC) Received: by mail-pj1-f52.google.com with SMTP id s21so7900104pjq.4 for ; Tue, 12 Jul 2022 08:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PVCxtziu69ypPL5baLDbqkUeAm+Vad851F8u5cx8lOU=; b=WAgI080vmtFPk69NUza6Dbq2aG5KAv/af8J9ue1zjHkKGo7hGrryj5ttPAhOXJ+c1I Qc/9oH2fjGAe06jXU2V7fzsPXj7ziWGehJAsacIyysKGlmhmqCYEYq2gSLLChpf5qOKh 9F9n0Uusnr7YWWBmgbMV7go7ESJz3KrtZorZpaBSt8/gGKyays1DjDUG2+XIl6bQdwvR rTS8tAtp6gCKys14qS8LGJS/nVafbHSG7TaxXtuKwW6bO7I7ctbsLFs624WgLLfYXEX6 fRChwTXMG6yfJ286oHSU3XqsITkxWh8DO4JBxYMo8kxcksukjQBe8O2gGlELpLqir3wt 9gMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PVCxtziu69ypPL5baLDbqkUeAm+Vad851F8u5cx8lOU=; b=2YcJAob1dOl6PNpfxYfNp31glrE6SIS9IN3CATKRTvj9HLbZZ0i9zS8bDdA+PdZsEm RIuGtrpu/6SYvURPSLq8mH9Q+nne0hqOH8YONM0lB3D1C780J5gRVo1iMczqo+PNVGO2 0+UDujuQrtirDOmZvyG2EVCCf5xitBTBgvAYXiAxotBWA5oq8Jgo8IsUNmDqhdhHfYg8 gaWdHtkmEWvOigH1IR4N8rDW7NS5Ghb/KbkVwy8++9olXqzEYBpLXFbBEVz5KK1SDHjS Id9rQoMXGJgFUh5yQ8kvRAVbMzv9qDSCAaWr5GJROY3ts2IZMKR7POvBoaSozTTDx38t D4RA== X-Gm-Message-State: AJIora8DPjGSBCYgwlP+qIczwnjtdmrF3+cp5HsAoVNSJhml+HpOlRvm xMhoA5kLO7WEM1ZCBuAL+7wHSF6AL1eIHEh6FwNyGw== X-Google-Smtp-Source: AGRyM1sv5Gbh5ZPu/A6moairXeSxW8wxQJ8yt+D2EwscGxLo3ku6ph8ISut0pYDZmca3iA9jJbZZp0PPR30NkwhKmpo= X-Received: by 2002:a17:90a:ba97:b0:1ef:91ab:de1e with SMTP id t23-20020a17090aba9700b001ef91abde1emr4998824pjr.237.1657639535861; Tue, 12 Jul 2022 08:25:35 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Shakeel Butt Date: Tue, 12 Jul 2022 08:25:24 -0700 Message-ID: Subject: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator. To: Michal Hocko , Yosry Ahmed , Muchun Song , Johannes Weiner Cc: Yafang Shao , Alexei Starovoitov , 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 Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657639538; a=rsa-sha256; cv=none; b=l59I/nL7FJcCoh71tqaYIHPs4d5tEYFhg1d1DVowDlvnK/tmoTGEPcSXcVQqwxudDswuan iJe5LqvhwzEUUdvjwl3XdAOQ+bGB5Dd5s4YOi9oVK2GjGBeRewIZ9oJBtpO2VsVNK3Cm1F kfSFyYqow06yadg5kx6dnP8q9ewHnZg= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=WAgI080v; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of shakeelb@google.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=shakeelb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657639538; 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=PVCxtziu69ypPL5baLDbqkUeAm+Vad851F8u5cx8lOU=; b=sCgOOYdlEV1eA0rwlhISk6AQN+jk5p+J1JKLINDtB/dRnfoLPvvwTwjMf5Cr/FwNNvjaQJ GEIDI2nuZ2ObLsjvqd2Ouo/4OXfmBaYFk6hkMg+D/KLL6XVgvimmkkEaf1Uu2RyVUtWhq4 95utV2PWmwIISNhCFVIYC+Dh6A3nlfk= X-Rspam-User: X-Stat-Signature: ecrgw1qo4fgyt77u1yr3mnhemps73nu6 X-Rspamd-Queue-Id: 26763C009B Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=WAgI080v; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of shakeelb@google.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=shakeelb@google.com X-Rspamd-Server: rspam03 X-HE-Tag: 1657639536-631897 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: CCing Yosry, Muchun & Johannes On Tue, Jul 12, 2022 at 2:52 AM 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. > > 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. Another very obvious example is the filesystem shared between multiple jobs. We had a similar discussion [1] on LRU reparenting patch series. For this use-case internally we have a memcg= mount option where the given memcg is the common ancestor (think of pod in k8s environment) of the jobs who are sharing the filesystem. [1] https://lore.kernel.org/all/20210330101531.82752-1-songmuchun@bytedance.com/