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 B0848C32772 for ; Fri, 19 Aug 2022 16:47:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 298388D0006; Fri, 19 Aug 2022 12:47:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 21F808D0002; Fri, 19 Aug 2022 12:47:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E9AE8D0006; Fri, 19 Aug 2022 12:47:44 -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 006E08D0002 for ; Fri, 19 Aug 2022 12:47:43 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id BEDC8C1A36 for ; Fri, 19 Aug 2022 16:47:43 +0000 (UTC) X-FDA: 79816923606.12.D1AFAED Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by imf09.hostedemail.com (Postfix) with ESMTP id 5288314003E for ; Fri, 19 Aug 2022 16:45:47 +0000 (UTC) Received: by mail-pj1-f54.google.com with SMTP id bf22so5140836pjb.4 for ; Fri, 19 Aug 2022 09:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc; bh=43IB1l85zFZx2xfIvsACnvdd0hD/Sqi80j0FvnZgz+w=; b=JQy2QfMvU993ELBmz2m2IaJHojQluWlc2EN1XG0ztr6V8OaUTHOJN6euMR6ZmYAlbl v0gDSEyBQCndO31qlao27Cg9HJjzj49/CDBem77UVSFkGSlC71Kw1brKSCMjzxi5Hfnj st8s2amoKpXOB2XplmnOm2Sony8Fk5a8Q21/jD4R+Vl1Ku3mG0/4G4ifVq6qmy0a8fuj apyv5fnK9IzqKogBCTmEjTQ3i6v3yXfFFJztAVKLeoGNEaP1vWx4w+k0o9AK2gZNiN+S kxlNRXmxImlpHp1cYsPdNZW3sHdtC2KjL+HkwJgEXQ7oaY97sWNrcStYnF/hITQJBwUo B13Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc; bh=43IB1l85zFZx2xfIvsACnvdd0hD/Sqi80j0FvnZgz+w=; b=FnGhVPPEpknQFJlKDaTdND+rL+H00na2rA4JzFGUqpcdOZ5FM8ad6zcD1yzVbxTCPG OxeiUcPDmzkOTJdsNE+NAOX/0+Kl00HDx/sU0LaasWKLqXJ4oSu0FNB9v3oDojuo5lNM F5OMHMEXS6T4LnUI449r8qpfvztG+Ot12INA5Qv32EP6dxt74VrtRP7DRjmszDnPOkSb CvndlBIbutwQfAP/Tbor3+V5BotrzOsRGlkQHXjLgLxfQQ7/XZrr7reYYT0WfJLBudpd 2N6jpOkQcYN2UxTvWwj5SBdLTwbe/UsPNZVI2tcKHaW7lct8+TXinfe2IZjCGil0Q7d1 NO2w== X-Gm-Message-State: ACgBeo08jHwMWP0Uk9jGxeTDC2qLByseSqFhVEEaTQ7NST5blwl8Wa9p hZYOEUoqA9BpIqhuCNNxlFk= X-Google-Smtp-Source: AA6agR7/XdV145+Mma974ZWG9OzesPe18qlL2A2CqA2hmJsnMTcginuIa1kkrjcH2PeZz70ips7QyA== X-Received: by 2002:a17:90b:1bce:b0:1fa:ecc3:9068 with SMTP id oa14-20020a17090b1bce00b001faecc39068mr2850604pjb.116.1660927546012; Fri, 19 Aug 2022 09:45:46 -0700 (PDT) Received: from localhost ([2620:10d:c090:400::5:db7d]) by smtp.gmail.com with ESMTPSA id k1-20020a170902c40100b00172a670607asm3442468plk.300.2022.08.19.09.45.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Aug 2022 09:45:45 -0700 (PDT) Date: Fri, 19 Aug 2022 06:45:43 -1000 From: Tejun Heo To: Yafang Shao Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin Lau , Song Liu , Yonghong Song , john fastabend , KP Singh , Stanislav Fomichev , Hao Luo , jolsa@kernel.org, Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , lizefan.x@bytedance.com, Cgroups , netdev , bpf , Linux MM Subject: Re: [PATCH bpf-next v2 00/12] bpf: Introduce selectable memcg for bpf map Message-ID: References: <20220818143118.17733-1-laoar.shao@gmail.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=1660927547; a=rsa-sha256; cv=none; b=7DlG+V8dejMtnbPSFMDiaen0wVfx7BfB6R2gK5RLTUqjKwViiaWPmtTX19y/AoMfgCU3Id AM3aXyLdJh84siCBpqxESr3ZJNNy+EBlIjuoYkQ5r8BQl3itI4fuHKlHpo7Qf9xySNX/B9 8suXw8C+UQ599VNKH2T55lGtpIQ2TWc= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=JQy2QfMv; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf09.hostedemail.com: domain of htejun@gmail.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=htejun@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660927547; 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=43IB1l85zFZx2xfIvsACnvdd0hD/Sqi80j0FvnZgz+w=; b=JJAq7Kx4S7qA3GlnaJRy7amDvdWqIS/HBQzeiqyWGXMwpiDHJ+mgVPp8S5qLkhu2+2sMhg uBqspbH3l5NRfWJbYDFk/pqbKekVqY/BwJRgFPsSjB2+GmA3dbOR5xYV8JjcKWNl2btOy0 NDPhx6HcSLJ1fTOBKSIuMpz2NQ34d2k= X-Stat-Signature: 377iqp3dbp36o6x9hi7mkzmc5578y7aw X-Rspamd-Queue-Id: 5288314003E X-Rspam-User: Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=JQy2QfMv; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf09.hostedemail.com: domain of htejun@gmail.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=htejun@gmail.com X-Rspamd-Server: rspam11 X-HE-Tag: 1660927547-218482 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, On Fri, Aug 19, 2022 at 08:59:20AM +0800, Yafang Shao wrote: > On Fri, Aug 19, 2022 at 6:20 AM Tejun Heo wrote: > > memcg folks would have better informed opinions but from generic cgroup pov > > I don't think this is a good direction to take. This isn't a problem limited > > to bpf progs and it doesn't make whole lot of sense to solve this for bpf. > > This change is bpf specific. It doesn't refactor a whole lot of things. I'm not sure what point the above sentence is making. It may not change a lot of code but it does introduce significantly new mode of operation which affects memcg and cgroup in general. > > We have the exact same problem for any resources which span multiple > > instances of a service including page cache, tmpfs instances and any other > > thing which can persist longer than procss life time. My current opinion is > > that this is best solved by introducing an extra cgroup layer to represent > > the persistent entity and put the per-instance cgroup under it. > > It is not practical on k8s. > Because, before the persistent entity, the cgroup dir is stateless. > After, it is stateful. > Pls, don't continue keeping blind eyes on k8s. Can you please elaborate why it isn't practical for k8s? I don't know the details of k8s and what you wrote above is not a detailed enough technical argument. > > It does require reorganizing how things are organized from userspace POV but > > the end result is really desirable. We get entities accurately representing > > what needs to be tracked and control over the granularity of accounting and > > control (e.g. folks who don't care about telling apart the current > > instance's usage can simply not enable controllers at the persistent entity > > level). > > Pls.s also think about why k8s refuse to use cgroup2. This attitude really bothers me. You aren't spelling it out fully but instead of engaging in the technical argument at the hand, you're putting forth conforming upstream to the current k8s's assumptions and behaviors as a requirement and then insisting that it's upstream's fault that k8s is staying with cgroup1. This is not an acceptable form of argument and it would be irresponsible to grant any kind weight to this line of reasoning. k8s may seem like the world to you but it is one of many use cases of the upstream kernel. We all should pay attention to the use cases and technical arguments to determine how we chart our way forward, but being k8s or whoever else clearly isn't a waiver to claim this kind of unilateral demand. It's okay to emphasize the gravity of the specific use case at hand but please realize that it's one of the many factors that should be considered and sometimes one which can and should get trumped by others. Thanks. -- tejun