From: Yonghong Song <yhs@fb.com> To: Yosry Ahmed <yosryahmed@google.com> Cc: Alexei Starovoitov <ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>, Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>, John Fastabend <john.fastabend@gmail.com>, KP Singh <kpsingh@kernel.org>, Hao Luo <haoluo@google.com>, Tejun Heo <tj@kernel.org>, Zefan Li <lizefan.x@bytedance.com>, Johannes Weiner <hannes@cmpxchg.org>, Shuah Khan <shuah@kernel.org>, Michal Hocko <mhocko@kernel.org>, Roman Gushchin <roman.gushchin@linux.dev>, David Rientjes <rientjes@google.com>, Stanislav Fomichev <sdf@google.com>, Greg Thelen <gthelen@google.com>, Shakeel Butt <shakeelb@google.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>, Cgroups <cgroups@vger.kernel.org> Subject: Re: [PATCH bpf-next v2 8/8] bpf: add a selftest for cgroup hierarchical stats collection Date: Tue, 28 Jun 2022 23:26:51 -0700 [thread overview] Message-ID: <59376285-21bc-ff12-3d64-3ea7257becb2@fb.com> (raw) In-Reply-To: <CAJD7tkbOztCEWgMzoCOdD+g3whMMQWW2e0gwo9p0tVK=3hqmcw@mail.gmail.com> On 6/28/22 12:43 AM, Yosry Ahmed wrote: > On Mon, Jun 27, 2022 at 11:47 PM Yosry Ahmed <yosryahmed@google.com> wrote: >> >> On Mon, Jun 27, 2022 at 11:14 PM Yonghong Song <yhs@fb.com> wrote: >>> >>> >>> >>> On 6/10/22 12:44 PM, Yosry Ahmed wrote: >>>> Add a selftest that tests the whole workflow for collecting, >>>> aggregating (flushing), and displaying cgroup hierarchical stats. >>>> >>>> TL;DR: >>>> - Whenever reclaim happens, vmscan_start and vmscan_end update >>>> per-cgroup percpu readings, and tell rstat which (cgroup, cpu) pairs >>>> have updates. >>>> - When userspace tries to read the stats, vmscan_dump calls rstat to flush >>>> the stats, and outputs the stats in text format to userspace (similar >>>> to cgroupfs stats). >>>> - rstat calls vmscan_flush once for every (cgroup, cpu) pair that has >>>> updates, vmscan_flush aggregates cpu readings and propagates updates >>>> to parents. >>>> >>>> Detailed explanation: >>>> - The test loads tracing bpf programs, vmscan_start and vmscan_end, to >>>> measure the latency of cgroup reclaim. Per-cgroup ratings are stored in >>>> percpu maps for efficiency. When a cgroup reading is updated on a cpu, >>>> cgroup_rstat_updated(cgroup, cpu) is called to add the cgroup to the >>>> rstat updated tree on that cpu. >>>> >>>> - A cgroup_iter program, vmscan_dump, is loaded and pinned to a file, for >>>> each cgroup. Reading this file invokes the program, which calls >>>> cgroup_rstat_flush(cgroup) to ask rstat to propagate the updates for all >>>> cpus and cgroups that have updates in this cgroup's subtree. Afterwards, >>>> the stats are exposed to the user. vmscan_dump returns 1 to terminate >>>> iteration early, so that we only expose stats for one cgroup per read. >>>> >>>> - An ftrace program, vmscan_flush, is also loaded and attached to >>>> bpf_rstat_flush. When rstat flushing is ongoing, vmscan_flush is invoked >>>> once for each (cgroup, cpu) pair that has updates. cgroups are popped >>>> from the rstat tree in a bottom-up fashion, so calls will always be >>>> made for cgroups that have updates before their parents. The program >>>> aggregates percpu readings to a total per-cgroup reading, and also >>>> propagates them to the parent cgroup. After rstat flushing is over, all >>>> cgroups will have correct updated hierarchical readings (including all >>>> cpus and all their descendants). >>>> >>>> Signed-off-by: Yosry Ahmed <yosryahmed@google.com> >>> >>> There are a selftest failure with test: >>> >>> get_cgroup_vmscan_delay:PASS:output format 0 nsec >>> get_cgroup_vmscan_delay:PASS:cgroup_id 0 nsec >>> get_cgroup_vmscan_delay:PASS:vmscan_reading 0 nsec >>> get_cgroup_vmscan_delay:PASS:read cgroup_iter 0 nsec >>> get_cgroup_vmscan_delay:PASS:output format 0 nsec >>> get_cgroup_vmscan_delay:PASS:cgroup_id 0 nsec >>> get_cgroup_vmscan_delay:FAIL:vmscan_reading unexpected vmscan_reading: >>> actual 0 <= expected 0 >>> check_vmscan_stats:FAIL:child1_vmscan unexpected child1_vmscan: actual >>> 781874 != expected 382092 >>> check_vmscan_stats:FAIL:child2_vmscan unexpected child2_vmscan: actual >>> -1 != expected -2 >>> check_vmscan_stats:FAIL:test_vmscan unexpected test_vmscan: actual >>> 781874 != expected 781873 >>> check_vmscan_stats:FAIL:root_vmscan unexpected root_vmscan: actual 0 < >>> expected 781874 >>> destroy_progs:PASS:remove cgroup_iter pin 0 nsec >>> destroy_progs:PASS:remove cgroup_iter pin 0 nsec >>> destroy_progs:PASS:remove cgroup_iter pin 0 nsec >>> destroy_progs:PASS:remove cgroup_iter pin 0 nsec >>> destroy_progs:PASS:remove cgroup_iter pin 0 nsec >>> destroy_progs:PASS:remove cgroup_iter pin 0 nsec >>> destroy_progs:PASS:remove cgroup_iter pin 0 nsec >>> destroy_progs:PASS:remove cgroup_iter root pin 0 nsec >>> cleanup_bpffs:PASS:rmdir /sys/fs/bpf/vmscan/ 0 nsec >>> #33 cgroup_hierarchical_stats:FAIL >>> >> >> The test is passing on my setup. I am trying to figure out if there is >> something outside the setup done by the test that can cause the test >> to fail. >> >>> >>> Also an existing test also failed. >>> >>> btf_dump_data:PASS:find type id 0 nsec >>> >>> >>> btf_dump_data:PASS:failed/unexpected type_sz 0 nsec >>> >>> >>> btf_dump_data:FAIL:ensure expected/actual match unexpected ensure >>> expected/actual match: actual '(union bpf_iter_link_info){.map = >>> (struct){.map_fd = (__u32)1,},.cgroup ' >>> test_btf_dump_struct_data:PASS:find struct sk_buff 0 nsec >>> >> >> Yeah I see what happened there. bpf_iter_link_info was changed by the >> patch that introduced cgroup_iter, and this specific union is used by >> the test to test the "union with nested struct" btf dumping. I will >> add a patch in the next version that updates the btf_dump_data test >> accordingly. Thanks. >> > > So I actually tried the attached diff to updated the expected dump of > bpf_iter_link_info in this test, but the test still failed: > > btf_dump_data:FAIL:ensure expected/actual match unexpected ensure > expected/actual match: actual '(union bpf_iter_link_info){.map = > (struct){.map_fd = (__u32)1,},.cgroup = (struct){.cgroup_fd = > (__u32)1,},}' != expected '(union bpf_iter_link_info){.map = > (struct){.map_fd = (__u32)1,},.cgroup = (struct){.cgroup_fd = > (__u32)1,.traversal_order = (__u32)1},}' > > It seems to me that the actual output in this case is not right, it is > missing traversal_order. Did we accidentally find a bug in btf dumping > of unions with nested structs, or am I missing something here? Probably there is an issue in btf_dump_data() function in tools/lib/bpf/btf_dump.c. Could you take a look at it? > Thanks! > >>> >>> test_btf_dump_struct_data:PASS:unexpected return value dumping sk_buff 0 >>> nsec >>> >>> btf_dump_data:PASS:verify prefix match 0 nsec >>> >>> >>> btf_dump_data:PASS:find type id 0 nsec >>> >>> >>> btf_dump_data:PASS:failed to return -E2BIG 0 nsec >>> >>> >>> btf_dump_data:PASS:ensure expected/actual match 0 nsec >>> >>> >>> btf_dump_data:PASS:verify prefix match 0 nsec >>> >>> >>> btf_dump_data:PASS:find type id 0 nsec >>> >>> >>> btf_dump_data:PASS:failed to return -E2BIG 0 nsec >>> >>> >>> btf_dump_data:PASS:ensure expected/actual match 0 nsec >>> >>> >>> #21/14 btf_dump/btf_dump: struct_data:FAIL >>> >>> please take a look. >>> >>>> --- >>>> .../prog_tests/cgroup_hierarchical_stats.c | 351 ++++++++++++++++++ >>>> .../bpf/progs/cgroup_hierarchical_stats.c | 234 ++++++++++++ >>>> 2 files changed, 585 insertions(+) >>>> create mode 100644 tools/testing/selftests/bpf/prog_tests/cgroup_hierarchical_stats.c >>>> create mode 100644 tools/testing/selftests/bpf/progs/cgroup_hierarchical_stats.c >>>> [...]
WARNING: multiple messages have this Message-ID (diff)
From: Yonghong Song <yhs-b10kYP2dOMg@public.gmane.org> To: Yosry Ahmed <yosryahmed-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> Cc: Alexei Starovoitov <ast-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Daniel Borkmann <daniel-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>, Andrii Nakryiko <andrii-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Martin KaFai Lau <kafai-b10kYP2dOMg@public.gmane.org>, Song Liu <songliubraving-b10kYP2dOMg@public.gmane.org>, John Fastabend <john.fastabend-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, KP Singh <kpsingh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Hao Luo <haoluo-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Zefan Li <lizefan.x-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org>, Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>, Shuah Khan <shuah-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Roman Gushchin <roman.gushchin-fxUVXftIFDnyG1zEObXtfA@public.gmane.org>, David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Stanislav Fomichev <sdf-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Greg Thelen <gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Linux Kernel Mailing List <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Networking <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, bpf <bpf-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> Subject: Re: [PATCH bpf-next v2 8/8] bpf: add a selftest for cgroup hierarchical stats collection Date: Tue, 28 Jun 2022 23:26:51 -0700 [thread overview] Message-ID: <59376285-21bc-ff12-3d64-3ea7257becb2@fb.com> (raw) In-Reply-To: <CAJD7tkbOztCEWgMzoCOdD+g3whMMQWW2e0gwo9p0tVK=3hqmcw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> On 6/28/22 12:43 AM, Yosry Ahmed wrote: > On Mon, Jun 27, 2022 at 11:47 PM Yosry Ahmed <yosryahmed-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote: >> >> On Mon, Jun 27, 2022 at 11:14 PM Yonghong Song <yhs-b10kYP2dOMg@public.gmane.org> wrote: >>> >>> >>> >>> On 6/10/22 12:44 PM, Yosry Ahmed wrote: >>>> Add a selftest that tests the whole workflow for collecting, >>>> aggregating (flushing), and displaying cgroup hierarchical stats. >>>> >>>> TL;DR: >>>> - Whenever reclaim happens, vmscan_start and vmscan_end update >>>> per-cgroup percpu readings, and tell rstat which (cgroup, cpu) pairs >>>> have updates. >>>> - When userspace tries to read the stats, vmscan_dump calls rstat to flush >>>> the stats, and outputs the stats in text format to userspace (similar >>>> to cgroupfs stats). >>>> - rstat calls vmscan_flush once for every (cgroup, cpu) pair that has >>>> updates, vmscan_flush aggregates cpu readings and propagates updates >>>> to parents. >>>> >>>> Detailed explanation: >>>> - The test loads tracing bpf programs, vmscan_start and vmscan_end, to >>>> measure the latency of cgroup reclaim. Per-cgroup ratings are stored in >>>> percpu maps for efficiency. When a cgroup reading is updated on a cpu, >>>> cgroup_rstat_updated(cgroup, cpu) is called to add the cgroup to the >>>> rstat updated tree on that cpu. >>>> >>>> - A cgroup_iter program, vmscan_dump, is loaded and pinned to a file, for >>>> each cgroup. Reading this file invokes the program, which calls >>>> cgroup_rstat_flush(cgroup) to ask rstat to propagate the updates for all >>>> cpus and cgroups that have updates in this cgroup's subtree. Afterwards, >>>> the stats are exposed to the user. vmscan_dump returns 1 to terminate >>>> iteration early, so that we only expose stats for one cgroup per read. >>>> >>>> - An ftrace program, vmscan_flush, is also loaded and attached to >>>> bpf_rstat_flush. When rstat flushing is ongoing, vmscan_flush is invoked >>>> once for each (cgroup, cpu) pair that has updates. cgroups are popped >>>> from the rstat tree in a bottom-up fashion, so calls will always be >>>> made for cgroups that have updates before their parents. The program >>>> aggregates percpu readings to a total per-cgroup reading, and also >>>> propagates them to the parent cgroup. After rstat flushing is over, all >>>> cgroups will have correct updated hierarchical readings (including all >>>> cpus and all their descendants). >>>> >>>> Signed-off-by: Yosry Ahmed <yosryahmed-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> >>> >>> There are a selftest failure with test: >>> >>> get_cgroup_vmscan_delay:PASS:output format 0 nsec >>> get_cgroup_vmscan_delay:PASS:cgroup_id 0 nsec >>> get_cgroup_vmscan_delay:PASS:vmscan_reading 0 nsec >>> get_cgroup_vmscan_delay:PASS:read cgroup_iter 0 nsec >>> get_cgroup_vmscan_delay:PASS:output format 0 nsec >>> get_cgroup_vmscan_delay:PASS:cgroup_id 0 nsec >>> get_cgroup_vmscan_delay:FAIL:vmscan_reading unexpected vmscan_reading: >>> actual 0 <= expected 0 >>> check_vmscan_stats:FAIL:child1_vmscan unexpected child1_vmscan: actual >>> 781874 != expected 382092 >>> check_vmscan_stats:FAIL:child2_vmscan unexpected child2_vmscan: actual >>> -1 != expected -2 >>> check_vmscan_stats:FAIL:test_vmscan unexpected test_vmscan: actual >>> 781874 != expected 781873 >>> check_vmscan_stats:FAIL:root_vmscan unexpected root_vmscan: actual 0 < >>> expected 781874 >>> destroy_progs:PASS:remove cgroup_iter pin 0 nsec >>> destroy_progs:PASS:remove cgroup_iter pin 0 nsec >>> destroy_progs:PASS:remove cgroup_iter pin 0 nsec >>> destroy_progs:PASS:remove cgroup_iter pin 0 nsec >>> destroy_progs:PASS:remove cgroup_iter pin 0 nsec >>> destroy_progs:PASS:remove cgroup_iter pin 0 nsec >>> destroy_progs:PASS:remove cgroup_iter pin 0 nsec >>> destroy_progs:PASS:remove cgroup_iter root pin 0 nsec >>> cleanup_bpffs:PASS:rmdir /sys/fs/bpf/vmscan/ 0 nsec >>> #33 cgroup_hierarchical_stats:FAIL >>> >> >> The test is passing on my setup. I am trying to figure out if there is >> something outside the setup done by the test that can cause the test >> to fail. >> >>> >>> Also an existing test also failed. >>> >>> btf_dump_data:PASS:find type id 0 nsec >>> >>> >>> btf_dump_data:PASS:failed/unexpected type_sz 0 nsec >>> >>> >>> btf_dump_data:FAIL:ensure expected/actual match unexpected ensure >>> expected/actual match: actual '(union bpf_iter_link_info){.map = >>> (struct){.map_fd = (__u32)1,},.cgroup ' >>> test_btf_dump_struct_data:PASS:find struct sk_buff 0 nsec >>> >> >> Yeah I see what happened there. bpf_iter_link_info was changed by the >> patch that introduced cgroup_iter, and this specific union is used by >> the test to test the "union with nested struct" btf dumping. I will >> add a patch in the next version that updates the btf_dump_data test >> accordingly. Thanks. >> > > So I actually tried the attached diff to updated the expected dump of > bpf_iter_link_info in this test, but the test still failed: > > btf_dump_data:FAIL:ensure expected/actual match unexpected ensure > expected/actual match: actual '(union bpf_iter_link_info){.map = > (struct){.map_fd = (__u32)1,},.cgroup = (struct){.cgroup_fd = > (__u32)1,},}' != expected '(union bpf_iter_link_info){.map = > (struct){.map_fd = (__u32)1,},.cgroup = (struct){.cgroup_fd = > (__u32)1,.traversal_order = (__u32)1},}' > > It seems to me that the actual output in this case is not right, it is > missing traversal_order. Did we accidentally find a bug in btf dumping > of unions with nested structs, or am I missing something here? Probably there is an issue in btf_dump_data() function in tools/lib/bpf/btf_dump.c. Could you take a look at it? > Thanks! > >>> >>> test_btf_dump_struct_data:PASS:unexpected return value dumping sk_buff 0 >>> nsec >>> >>> btf_dump_data:PASS:verify prefix match 0 nsec >>> >>> >>> btf_dump_data:PASS:find type id 0 nsec >>> >>> >>> btf_dump_data:PASS:failed to return -E2BIG 0 nsec >>> >>> >>> btf_dump_data:PASS:ensure expected/actual match 0 nsec >>> >>> >>> btf_dump_data:PASS:verify prefix match 0 nsec >>> >>> >>> btf_dump_data:PASS:find type id 0 nsec >>> >>> >>> btf_dump_data:PASS:failed to return -E2BIG 0 nsec >>> >>> >>> btf_dump_data:PASS:ensure expected/actual match 0 nsec >>> >>> >>> #21/14 btf_dump/btf_dump: struct_data:FAIL >>> >>> please take a look. >>> >>>> --- >>>> .../prog_tests/cgroup_hierarchical_stats.c | 351 ++++++++++++++++++ >>>> .../bpf/progs/cgroup_hierarchical_stats.c | 234 ++++++++++++ >>>> 2 files changed, 585 insertions(+) >>>> create mode 100644 tools/testing/selftests/bpf/prog_tests/cgroup_hierarchical_stats.c >>>> create mode 100644 tools/testing/selftests/bpf/progs/cgroup_hierarchical_stats.c >>>> [...]
next prev parent reply other threads:[~2022-06-29 6:27 UTC|newest] Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-06-10 19:44 [PATCH bpf-next v2 0/8] bpf: rstat: cgroup hierarchical stats Yosry Ahmed 2022-06-10 19:44 ` [PATCH bpf-next v2 1/8] cgroup: enable cgroup_get_from_file() on cgroup1 Yosry Ahmed 2022-06-10 19:44 ` [PATCH bpf-next v2 2/8] cgroup: Add cgroup_put() in !CONFIG_CGROUPS case Yosry Ahmed 2022-06-10 19:44 ` Yosry Ahmed 2022-06-10 19:44 ` [PATCH bpf-next v2 3/8] bpf, iter: Fix the condition on p when calling stop Yosry Ahmed 2022-06-20 18:48 ` Yonghong Song 2022-06-21 7:25 ` Hao Luo 2022-06-24 17:46 ` Yonghong Song 2022-06-24 17:46 ` Yonghong Song 2022-06-24 18:23 ` Yosry Ahmed 2022-06-24 18:23 ` Yosry Ahmed 2022-06-10 19:44 ` [PATCH bpf-next v2 4/8] bpf: Introduce cgroup iter Yosry Ahmed 2022-06-11 6:23 ` kernel test robot 2022-06-11 7:34 ` kernel test robot 2022-06-11 12:44 ` kernel test robot 2022-06-11 12:55 ` kernel test robot 2022-06-11 12:55 ` kernel test robot 2022-06-28 4:09 ` Yonghong Song 2022-06-28 4:09 ` Yonghong Song 2022-06-28 6:06 ` Yosry Ahmed 2022-06-28 6:06 ` Yosry Ahmed 2022-07-07 23:33 ` Hao Luo 2022-06-28 4:14 ` Yonghong Song 2022-06-28 4:14 ` Yonghong Song 2022-06-28 6:03 ` Yosry Ahmed 2022-06-28 6:03 ` Yosry Ahmed 2022-06-28 17:03 ` Yonghong Song 2022-06-28 17:03 ` Yonghong Song 2022-07-07 23:36 ` Hao Luo 2022-06-10 19:44 ` [PATCH bpf-next v2 5/8] selftests/bpf: Test cgroup_iter Yosry Ahmed 2022-06-10 19:44 ` Yosry Ahmed 2022-06-28 6:11 ` Yonghong Song 2022-06-10 19:44 ` [PATCH bpf-next v2 6/8] cgroup: bpf: enable bpf programs to integrate with rstat Yosry Ahmed 2022-06-10 20:52 ` kernel test robot 2022-06-10 20:52 ` kernel test robot 2022-06-10 21:22 ` kernel test robot 2022-06-10 21:30 ` Yosry Ahmed 2022-06-10 21:30 ` Yosry Ahmed 2022-06-10 21:30 ` Yosry Ahmed 2022-06-11 19:57 ` Alexei Starovoitov 2022-06-11 19:57 ` Alexei Starovoitov 2022-06-11 19:57 ` Alexei Starovoitov 2022-06-13 17:05 ` Yosry Ahmed 2022-06-13 17:05 ` Yosry Ahmed 2022-06-13 17:05 ` Yosry Ahmed 2022-06-11 10:22 ` kernel test robot 2022-06-28 6:12 ` Yonghong Song 2022-06-10 19:44 ` [PATCH bpf-next v2 7/8] selftests/bpf: extend cgroup helpers Yosry Ahmed 2022-06-10 19:44 ` [PATCH bpf-next v2 8/8] bpf: add a selftest for cgroup hierarchical stats collection Yosry Ahmed 2022-06-28 6:14 ` Yonghong Song 2022-06-28 6:14 ` Yonghong Song 2022-06-28 6:47 ` Yosry Ahmed 2022-06-28 6:47 ` Yosry Ahmed 2022-06-28 7:14 ` Yosry Ahmed 2022-06-28 7:14 ` Yosry Ahmed 2022-06-29 0:09 ` Yosry Ahmed 2022-06-29 0:09 ` Yosry Ahmed 2022-06-29 6:48 ` Yonghong Song 2022-06-29 6:48 ` Yonghong Song 2022-06-29 8:04 ` Yosry Ahmed 2022-06-29 8:04 ` Yosry Ahmed 2022-07-02 0:55 ` Yonghong Song 2022-07-02 0:55 ` Yonghong Song 2022-07-06 21:29 ` Yosry Ahmed 2022-07-06 21:29 ` Yosry Ahmed 2022-06-29 6:17 ` Yonghong Song 2022-06-29 6:17 ` Yonghong Song 2022-06-28 7:43 ` Yosry Ahmed 2022-06-28 7:43 ` Yosry Ahmed 2022-06-29 6:26 ` Yonghong Song [this message] 2022-06-29 6:26 ` Yonghong Song 2022-06-29 8:03 ` Yosry Ahmed 2022-06-29 8:03 ` Yosry Ahmed 2022-07-01 23:28 ` Hao Luo 2022-07-01 23:28 ` Hao Luo 2022-06-10 19:48 ` [PATCH bpf-next v2 0/8] bpf: rstat: cgroup hierarchical stats Yosry Ahmed 2022-06-10 19:48 ` Yosry Ahmed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=59376285-21bc-ff12-3d64-3ea7257becb2@fb.com \ --to=yhs@fb.com \ --cc=andrii@kernel.org \ --cc=ast@kernel.org \ --cc=bpf@vger.kernel.org \ --cc=cgroups@vger.kernel.org \ --cc=daniel@iogearbox.net \ --cc=gthelen@google.com \ --cc=hannes@cmpxchg.org \ --cc=haoluo@google.com \ --cc=john.fastabend@gmail.com \ --cc=kafai@fb.com \ --cc=kpsingh@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lizefan.x@bytedance.com \ --cc=mhocko@kernel.org \ --cc=netdev@vger.kernel.org \ --cc=rientjes@google.com \ --cc=roman.gushchin@linux.dev \ --cc=sdf@google.com \ --cc=shakeelb@google.com \ --cc=shuah@kernel.org \ --cc=songliubraving@fb.com \ --cc=tj@kernel.org \ --cc=yosryahmed@google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.