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 DBFE1C433FE for ; Fri, 18 Mar 2022 19:59:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 09B248D0002; Fri, 18 Mar 2022 15:59:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 04A958D0001; Fri, 18 Mar 2022 15:59:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E581E8D0002; Fri, 18 Mar 2022 15:59:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id D59928D0001 for ; Fri, 18 Mar 2022 15:59:29 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A8867203FD for ; Fri, 18 Mar 2022 19:59:29 +0000 (UTC) X-FDA: 79258571658.15.F37567A Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf27.hostedemail.com (Postfix) with ESMTP id 1F6CC40031 for ; Fri, 18 Mar 2022 19:59:28 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 7FCC0B80682 for ; Fri, 18 Mar 2022 19:59:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2C9B2C340EF for ; Fri, 18 Mar 2022 19:59:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1647633566; bh=Q/AneTN6VK0FKM8VUMmAL24sxlKXjApD+7URsOBBLys=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=fzwYuq1QWgluY2rLULh5F1cIB7CH4nKOrZPexeaBZc3eqdzDEUv+4hdZPHE/gD7lm AAWg2sHe+IiUwHYpGjhmmFn5/PJ2zjgbwMhfdLGS2H4SxfTP4N/NOfvFRAMnW8VWFy yimWypwcTTA3MjnqBAZ/RlnvhG/U3n37aFDxPygWEA81gV6QKBLBs2RYCQF9DB2v91 DGKG6Ks4/cjqlRTweaFd53BWPIsYf+32FeAKYmVzVF6K4w3tUr6MFX6ZQbUEMbqBe0 bYnXIIXo0to0tqAWBxdDupDHEA7/xxy6GoWnuMHPSl0tcZIz3z+LTQEt8ewmEK/H4d SXiYQbiRZVVrg== Received: by mail-yb1-f181.google.com with SMTP id u3so17696242ybh.5 for ; Fri, 18 Mar 2022 12:59:26 -0700 (PDT) X-Gm-Message-State: AOAM533LwwiDMCjInXvkiUlZfrOg9jjUF+XI1YeFG6f7r8nl4gFVQLrR Z8TndfQbgi4o5uOqN052g0g9TKUgzyK5e4jOwDM= X-Google-Smtp-Source: ABdhPJz60lYU2HlnD1hDpuqy9kgjbRFCqrqnEE+OGFeSw2OQ9ikRZ7G7LryM455CYwDhOylz4jvJGp735eCzAMh/9ms= X-Received: by 2002:a25:40d3:0:b0:633:bb21:2860 with SMTP id n202-20020a2540d3000000b00633bb212860mr4386656yba.9.1647633565201; Fri, 18 Mar 2022 12:59:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Song Liu Date: Fri, 18 Mar 2022 12:59:14 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC bpf-next] Hierarchical Cgroup Stats Collection Using BPF To: Yosry Ahmed , Namhyung Kim Cc: Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Johannes Weiner , Hao Luo , Shakeel Butt , Stanislav Fomichev , David Rientjes , bpf , KP Singh , cgroups@vger.kernel.org, Linux-MM Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Queue-Id: 1F6CC40031 X-Stat-Signature: dp1afa7fu3jcsfhdyryzw7b6bzr1963a Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=fzwYuq1Q; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of song@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=song@kernel.org X-Rspamd-Server: rspam03 X-HE-Tag: 1647633568-174939 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 Wed, Mar 9, 2022 at 12:27 PM Yosry Ahmed wrote: > > Hey everyone, > > I would like to discuss an idea to facilitate collection of > hierarchical cgroup stats using BPF programs. We want to provide a > simple interface for BPF programs to collect hierarchical cgroup stats > and integrate with the existing rstat aggregation mechanism in the > kernel. The most prominent use case is the ability to extend memcg > stats (and histograms) by BPF programs. > + Namhyung, I forgot to mention this in the office hour. The aggregation efficiency problem is actually similar to Namhyung's work to use BPF programs to aggregate perf counters. Check: tools/perf/util/bpf_skel/bperf_cgroup.bpf.c Namhyung's solution is to walk up the cgroup tree on cgroup switch events. This may not be as efficient as rstat flush logic, but I think it is good enough for many use cases (unless the cgroup tree is very deep). It also demonstrates how we can implement some cgroup logic in BPF. I hope this helps. Thanks, Song [...]