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 B970AC00140 for ; Fri, 19 Aug 2022 01:10:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 445EE8D0003; Thu, 18 Aug 2022 21:10:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CE1B8D0002; Thu, 18 Aug 2022 21:10:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 26EA18D0003; Thu, 18 Aug 2022 21:10:04 -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 145828D0002 for ; Thu, 18 Aug 2022 21:10:04 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id DF4E3ABFF6 for ; Fri, 19 Aug 2022 01:10:03 +0000 (UTC) X-FDA: 79814560686.16.1F1FD94 Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) by imf10.hostedemail.com (Postfix) with ESMTP id F2D03C001A for ; Fri, 19 Aug 2022 01:10:02 +0000 (UTC) Received: by mail-vs1-f47.google.com with SMTP id m66so3136650vsm.12 for ; Thu, 18 Aug 2022 18:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=a+4YJ1LhJSNyK/sLr7JdvqPtNEtaZ4Z5AzpDGJs51kw=; b=h+9pelx8eiiyd0IkVd1BlXhfKkkVTdikoxVEKKTeMkhxIYLKe9yfAYzjs4f1ZmtKrU AoIO1SoacdD8rFz8JbEeRcVXK+nyPNnmo9MuTYvBPQi0wq1e2UIUwVL+wNpCpTvqPBvw 6HiikZi3QWNvcmRMnTEuua2YNoKu0s2gQqiqh+E/IH+HSL8s7GbQtAnN9kQPx1uZxF/n g/1vQg5vuVOfW/XT0wbQtQ148FtewpbQ3dV/NKwl+wU0yzni5gqS2EpN1SuhoQAUNx6v sBY81kKYi4HXys1m7OQpV6+gybAhuqRD1NmMJZ9kgHuwLGW/vdVmmBGbEw4Wk5QYRd6p uoMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=a+4YJ1LhJSNyK/sLr7JdvqPtNEtaZ4Z5AzpDGJs51kw=; b=6sSNCnyuPa+hsnVCw8f4fC6H3TgNeeutAeUjhHyHqtIxiSUS4gc79n3cqrVsx4TC8A Yceg1JG4oI1I4mnojpPypNrXX8Bv7AwzF60fOZK7UNu6IGS5kSpMXisvcUc8ZgVZbuTm d1FvIaKRmyBt3k0W6Ftw8N3fQcgACqMw0CZy/hBpO4aTEc6ryAlpwaVXr1cUrVorDV22 Nqih5YWkM+0MHHpn65lyxlWZpQYZWJd9eqaYEJPjwmtt4+PqcJM2Sg+B3JASChgKz/T4 eC92F2+fRmJ/rdUoQKqhS8O9wOpJQ+dFyqimcUXQKH23OeGB2RN63YndcLvt5oSbSTol HV6Q== X-Gm-Message-State: ACgBeo34JPrrK3qlIF6iRaX5O2xls0uiu/kU/ZE3nM1KcLcFU05lRFns V+UDD8radZxEChB01eMg9o8zKhiHIA3n3dgSg9U= X-Google-Smtp-Source: AA6agR61Oz/IzjKiBVm75sJ2/yHFLftaP8V01ijTbHM1H9PG+RiBdgq0LsaeUAx4kcfnWkXvkcm6noi2/eLvHbtBRiM= X-Received: by 2002:a67:d50c:0:b0:38a:c107:25e0 with SMTP id l12-20020a67d50c000000b0038ac10725e0mr2073409vsj.11.1660871402196; Thu, 18 Aug 2022 18:10:02 -0700 (PDT) MIME-Version: 1.0 References: <20220818143118.17733-1-laoar.shao@gmail.com> In-Reply-To: From: Yafang Shao Date: Fri, 19 Aug 2022 09:09:25 +0800 Message-ID: Subject: Re: [PATCH bpf-next v2 00/12] bpf: Introduce selectable memcg for bpf map To: Tejun Heo 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 Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660871402; 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=a+4YJ1LhJSNyK/sLr7JdvqPtNEtaZ4Z5AzpDGJs51kw=; b=mfsf7X6eb+Mwtp2h7Rp7diFRlCO+XDq6u63O5zVNPjZAfSWWqLjqEfyBzerLhJsPtYT8rB OeWxHlUjkKZF253oAUQAe+LAcPdHSi+tqtNtw9hefDxANcRlajlo66C4JI1q6jRALwJiZy Vcr4YQ6gFjKLDwsBuJA8rdT12paz4IY= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=h+9pelx8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf10.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.217.47 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660871402; a=rsa-sha256; cv=none; b=OuwtOQIctfPSHlbDjLygjFSwrxrX3KhQ+pewF8Q234NU+FCOOfVD3urY8KgiW71UlVTMq5 jY2/rEbzTbzv7VAFSw1UNRcZgh48ivBzHdjfFXqrS/pgDELW/CoPcprnxeNOybW6bhj4pU zeEen7mUXNIYpK8tV5FSmAjjU5GwBcQ= X-Stat-Signature: xduzc3nzjte76igyu15kd38kzpx1qbkj X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: F2D03C001A Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=h+9pelx8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf10.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.217.47 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com X-Rspam-User: X-HE-Tag: 1660871402-74529 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 Fri, Aug 19, 2022 at 6:33 AM Tejun Heo wrote: > > On Thu, Aug 18, 2022 at 12:20:33PM -1000, Tejun Heo wrote: > > 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 > > To expand a bit more on this point, once we start including page cache and > tmpfs, we now get entangled with memory reclaim which then brings in IO and > not-yet-but-eventually CPU usage. Introduce-a-new-layer vs introduce-a-new-cgroup, which one is more overhead? > Once you start splitting the tree like > you're suggesting here, all those will break down and now we have to worry > about how to split resource accounting and control for the same entities > across two split branches of the tree, which doesn't really make any sense. > The k8s has already been broken thanks to the memcg accounting on bpf memory. If you ignored it, I paste it below. [0]"1. The memory usage is not consistent between the first generation and new generations." This issue will persist even if you introduce a new layer. > So, we *really* don't wanna paint ourselves into that kind of a corner. This > is a dead-end. Please ditch it. > It makes non-sensen to ditch it. Because, the hierarchy I described in the commit log is *one* use case of the selectable memcg, but not *the only one* use case of it. If you dislike that hierarchy, I will remove it to avoid misleading you. Even if you introduce a new layer, you still need the selectable memcg. For example, to avoid the issue I described in [0], you still need to charge to the parent cgroup instead of the current cgroup. That's why I described in the commit log that the selectable memcg is flexible. -- Regards Yafang