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 56B67C43334 for ; Wed, 13 Jul 2022 16:24:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A71056B010C; Wed, 13 Jul 2022 12:24:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A20F66B010D; Wed, 13 Jul 2022 12:24:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E7EB940134; Wed, 13 Jul 2022 12:24:52 -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 7C0DD6B010C for ; Wed, 13 Jul 2022 12:24:52 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 476EC207B8 for ; Wed, 13 Jul 2022 16:24:52 +0000 (UTC) X-FDA: 79682600424.22.B56585E Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) by imf28.hostedemail.com (Postfix) with ESMTP id E01D0C0084 for ; Wed, 13 Jul 2022 16:24:51 +0000 (UTC) Received: by mail-pj1-f42.google.com with SMTP id g16-20020a17090a7d1000b001ea9f820449so4471542pjl.5 for ; Wed, 13 Jul 2022 09:24:51 -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=I4nXvTrHWqcaRh/wbTzKGKZr7mZYOjAz89tRpbel2lU=; b=SZ0OMHcl16lDAPcha/JzO8rJCaPX76K7/6/3XLhB7qHjcKUk9LXRnPy+O2nh1LSV7J viBzimQ2JjqMAWA/4xCNxjwIeGW6U/W2GZtQF9iETtQN1IQ+A7HcIHFeHYjDy++onEsY NcKgqxms+1XMjfqrZvS/q5cPEqn5ga6FsWJVtDYqaT+Cw894oAuqRcJ0d/SJv2hQ/mQD xdMUtDr45yNNLUfXRt0QPFui5FI4MYRox046jBj8uIAoCf1TcXKHXjdSZj5nQPdWOj7E IEAoYXNyf78jiexRR0FDh9Lp3YgeUVFlEgWsZXw+KyEpS0WsY93VxOWMVnS9g7jaP9k0 ++eg== 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=I4nXvTrHWqcaRh/wbTzKGKZr7mZYOjAz89tRpbel2lU=; b=N7am4QlL1fPEb0qZX7Q7VRLFRxmwkUmuS0vzu7ATHzqM1buAmnwf2HVmbtDMca6nlH wF7Qs9RjcVo0akkT19R8HxCwPC8LHFuwGtzJVeDo2e3VCCnC0MKqqLrPBieCt8JYOG+e OobUH0wfSRnmCz1dp2prm0StRDX4w1rqs0jdhsFT2jEinilpIB3kQ4qaxGQEXlqut3fF V/P7jLVNkUXjJYbP2TgX8mKy7c7tCPwMUT1aGC64Ij89PTU07p24Z+OgxCVGMJnm8CSw Q1p3Zd0mtADHgFc1KIUUp+acDr0NzUtDr1GYDpVDsgyfO+y6XQPoiTWZwAZZFN6xmu26 8FNA== X-Gm-Message-State: AJIora+Idq//xrfYVL7IOg3WLJLCnDh0vCz7D6wlxMWr7iE+X2kWIIhs nrGi8qAdOtrUNIijE3/5jTQ= X-Google-Smtp-Source: AGRyM1sxbJngnxCbXSmHXDaneeDVQH+0ZxZY+ACvkLdHP5FmVF3FPZr//WEBV9Di82SPEZRwy/OhkA== X-Received: by 2002:a17:902:d64a:b0:16c:2755:428d with SMTP id y10-20020a170902d64a00b0016c2755428dmr3860778plh.79.1657729490543; Wed, 13 Jul 2022 09:24:50 -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 r7-20020aa79627000000b005289ffefe82sm9098272pfg.130.2022.07.13.09.24.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Jul 2022 09:24:49 -0700 (PDT) Date: Wed, 13 Jul 2022 06:24:47 -1000 From: Tejun Heo To: Yafang Shao Cc: Roman Gushchin , Michal Hocko , 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: <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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657729492; 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=I4nXvTrHWqcaRh/wbTzKGKZr7mZYOjAz89tRpbel2lU=; b=7jQvm5oeN6RKbGoF/8CP0LfJVfnOZXx8kcsobnRRz4lWTdjQVjzfhzAe6Ci8ar/HJlTHKX WTYMD9Ly9qdsgNfzP4fuL513eqeeEH8ZLBrsHt/g0LX+gBpfOTJcyozyvx188a1NZPdchy gtTQ/S00ygoD14LHKz0064OMtGEFlQM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657729492; a=rsa-sha256; cv=none; b=5ryuDIvQ6p8OK0wvunOIupEXE2YE6E2uzcLAe4UZrvydcLrRZlkdNq+1jf/Lu8oEIA4Z6H HZeYXRNwpj80Ga0nQ45RNOxsN016OOusqozqFcqCNOGvnoHw4gsJ/CTsVcII9QLdG+vdIV nrbbNo15DlQX73swEQ4dvetcciAC4fM= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=SZ0OMHcl; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf28.hostedemail.com: domain of htejun@gmail.com designates 209.85.216.42 as permitted sender) smtp.mailfrom=htejun@gmail.com X-Stat-Signature: cr767e7ojf6cr1syi6ccnz7p6p6exrj4 X-Rspamd-Queue-Id: E01D0C0084 X-Rspam-User: Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=SZ0OMHcl; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf28.hostedemail.com: domain of htejun@gmail.com designates 209.85.216.42 as permitted sender) smtp.mailfrom=htejun@gmail.com X-Rspamd-Server: rspam05 X-HE-Tag: 1657729491-175777 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 Wed, Jul 13, 2022 at 10:24:05PM +0800, Yafang Shao wrote: > I have told you that it is not reasonable to refuse a containerized > process to pin bpf programs, but if you are not familiar with k8s, it > is not easy to explain clearly why it is a trouble for deployment. > But I can try to explain to you from a *systemd user's* perspective. The way systemd currently sets up cgroup hierarchy doesn't work for persistent per-service resource tracking. It needs to introduce an extra layer for that which woudl be a significant change for systemd too. > I assume the above hierarchy is what you expect. > But you know, in the k8s environment, everything is pod-based, that > means if we use the above hierarchy in the k8s environment, the k8s's > limiting, monitoring, debugging must be changed consequently. That > means it may be a fullstack change in k8s, a great refactor. > > So below hierarchy is a reasonable solution, > bpf-memcg > | > bpf-foo pod bpf-foo-memcg (limited) > / \ / > (charge) (not-charged) (charged) > proc-foo bpf-foo > > And then keep the bpf-memgs persistent. It looks like you draw the diagram with variable width font and it's difficult to tell what you're trying to say. That said, I don't think the argument you're making is a good one in general. The topic at hand is future architectural direction in handling shared resources, which was never well supported before. ie. We're not talking about breaking existing behaviors. We don't want to architect kernel features to suit the expectations of one particular application. It has to be longer term than that and it can't be an one way road. Sometimes the kernel adapts to existing applications because the expectations make sense. At other times, kernel takes a direction which may require some work from applications to use new capabilities because that makes more sense in the long term. Let's keep the discussion more focused on technical merits. Thanks. -- tejun