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 55A27C32771 for ; Sat, 24 Sep 2022 14:25:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 58BC98E0006; Sat, 24 Sep 2022 10:25:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 53B7C8E0005; Sat, 24 Sep 2022 10:25:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DBC08E0006; Sat, 24 Sep 2022 10:25:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 2BCB78E0005 for ; Sat, 24 Sep 2022 10:25:32 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id E8395AB0F0 for ; Sat, 24 Sep 2022 14:25:31 +0000 (UTC) X-FDA: 79947202062.27.317BA5C Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) by imf31.hostedemail.com (Postfix) with ESMTP id 8FA592000E for ; Sat, 24 Sep 2022 14:25:31 +0000 (UTC) Received: by mail-lf1-f44.google.com with SMTP id a3so4390205lfk.9 for ; Sat, 24 Sep 2022 07:25:31 -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:subject:date; bh=jRKeU7D5aZgqxcjhpKNi6s8l4B1Pu/W+vLp64/SXJ2k=; b=UpNAHeRltGJnNUYU6IN+U1QlRe0AbcVc4toc+QBqstl7xLFBtoVNVlln1qx7x6FHxq rzY/D8LfF8p4hcesvrFXHhGlDSwavN4UvN0Wf7LEkbN6RSQ4f3v1Spc+hnP3SMOd28s3 lnPp5Fie6yB/oSzot5F4zNN7C871LEqZ5grBwldPWgx3HhBMNzb+f6edYQXL1ri9oZ0S Go4e9VTTw0+XaHP7aG0MvZJjlbheySZtr3aSZogGWCrLGK0YX5Eeil5Dasn8Sf6dIobv FKQG9KNOV2QdrzCjAv9xJCHfHZdSwEXrmDHKT2LfmqnahX+L+U2ulngUzqfy0WZSoING bk+w== 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:subject:date; bh=jRKeU7D5aZgqxcjhpKNi6s8l4B1Pu/W+vLp64/SXJ2k=; b=ksvHWYZm3Pku034wetCmFm/fzyAPWwyB7I0hOuSCzR5Ls/mJGXMZrAA3CycZO5zxFW FoVzuVVOX1iL/HduhR/QMJDHiCWUFl/Qs0TeLmDL2PNQ4vGtXW141Z8BWD4TvTueuqB6 hrR6dqyd0jMIXoy3OCSryq3vcEpqoUYuae6DRSldZAfi11bIFVUw4T6L5MgH2Z4znVPJ l7WYa2XVkHdjOV3NB+sj9FmGFTF1thcXHOV9/MdGoZ391Dfgf6byiG1GvT0p2VDq6cvz tEEHWmuIbHy24JNntjPRF5CkLkOqwRq97zcuc5Rv284GyzMpPBmPVlEqIU9Qyx+QvzuJ W3kg== X-Gm-Message-State: ACrzQf3Pl+Zzlvoe3AhK8DQG+v3ZJIPt6N5OjlQPwkbyERzt1DaHp3Pn tG+jdUfWraP0CGfkDQJzLy0jIMxXYt/cjhJx7nc= X-Google-Smtp-Source: AMsMyM5mi/XOOzWUJh5158inAtWdLBfxcxDHHgcvsLaTz0IhKhNVd6IYu367qB1zcyRs2jUK93uUOFjSKv49EhHqRbE= X-Received: by 2002:a05:6512:2254:b0:498:f454:ec9a with SMTP id i20-20020a056512225400b00498f454ec9amr5457526lfu.58.1664029529792; Sat, 24 Sep 2022 07:25:29 -0700 (PDT) MIME-Version: 1.0 References: <20220921170002.29557-1-laoar.shao@gmail.com> <20220921170002.29557-11-laoar.shao@gmail.com> In-Reply-To: From: Yafang Shao Date: Sat, 24 Sep 2022 22:24:52 +0800 Message-ID: Subject: Re: [RFC PATCH bpf-next 10/10] bpf, memcg: Add new item bpf into memory.stat To: Tejun Heo Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin Lau , Song Liu , Yonghong Song , john fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , Zefan Li , Cgroups , netdev , bpf , Linux MM Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664029531; a=rsa-sha256; cv=none; b=kF1NltrIh7WF8BmlFnFQtRte/eJCQovWJcEvaAgIV+KMMk0O8sjIwlLMcIiINmFS8AieMt fFoqoW4O6c6VXE38t377M8TpSYHaJ6SWr8k7HHPlq2FWXI9BicsWs9AeCN9OGP7q1wfffb ns4melhUPoG509Oo6TVtgUc9HASbkfc= ARC-Authentication-Results: i=1; imf31.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=UpNAHeRl; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf31.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664029531; 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=jRKeU7D5aZgqxcjhpKNi6s8l4B1Pu/W+vLp64/SXJ2k=; b=X6qtN6aVJsAOJfEwB76ZpiiiXaBGqDF5Ho8hPZnOefw7tD35JmW51SD66GrovOFhp+bBRF VEwXsjWGfn0NyM/5HAxpynYDfvUWC/oGVt5+s+Ir6jdVAloJN4O0KAjIiUzQh7ORzcaJs6 U3gTGEvuYH498+etMv+5LUcHj629j4o= X-Rspamd-Server: rspam11 X-Rspam-User: X-Rspamd-Queue-Id: 8FA592000E Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=UpNAHeRl; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf31.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com X-Stat-Signature: jrbuhpyxinf7ercpm7s6qjgjzcxpzpn4 X-HE-Tag: 1664029531-21413 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 Sat, Sep 24, 2022 at 11:20 AM Tejun Heo wrote: > > Hello, > > On Wed, Sep 21, 2022 at 05:00:02PM +0000, Yafang Shao wrote: > > A new item 'bpf' is introduced into memory.stat, then we can get the memory > > consumed by bpf. Currently only the memory of bpf-map is accounted. > > The accouting of this new item is implemented with scope-based accouting, > > which is similar to set_active_memcg(). In this scope, the memory allocated > > will be accounted or unaccounted to a specific item, which is specified by > > set_active_memcg_item(). > > Imma let memcg folks comment on the implementation. Hmm... I wonder how this > would tie in with the BPF memory allocator Alexei is working on. > BPF memory allocator is already in bpf-next [1]. It uses the same way to charge bpf memory into memcg, see also get_memcg() in the BPF memory allocator, so it has been supported in this patchset. [1]. https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=274052a2b0ab9f380ce22b19ff80a99b99ecb198 > > The result in cgroup v1 as follows, > > $ cat /sys/fs/cgroup/memory/foo/memory.stat | grep bpf > > bpf 109056000 > > total_bpf 109056000 > > After the map is removed, the counter will become zero again. > > $ cat /sys/fs/cgroup/memory/foo/memory.stat | grep bpf > > bpf 0 > > total_bpf 0 > > > > The 'bpf' may not be 0 after the bpf-map is destroyed, because there may be > > cached objects. > > What's the difference between bpf and total_bpf? Where's total_bpf > implemented? Ah, the total_* items are cgroup1-specific items. They also include the descendants' memory. This patchset supports both cgroup1 and cgroup2. > It doesn't seem to be anywhere. Please also update > Documentation/admin-guide/cgroup-v2.rst. > Sure, I will update the Document. > > Note that there's no kmemcg in root memory cgroup, so the item 'bpf' will > > be always 0 in root memory cgroup. If a bpf-map is charged into root memcg > > directly, its memory size will not be accounted, so the 'total_bpf' can't > > be used to monitor system-wide bpf memory consumption yet. > > So, system-level accounting is usually handled separately as it's most > likely that we'd want the same stat at the system level even when cgroup is > not implemented. Here, too, it'd make sense to first implement system level > bpf memory usage accounting, expose that through /proc/meminfo and then use > the same source for root level cgroup stat. > Sure, I will do it first. Thanks for your suggestion. -- Regards Yafang