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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D41AFC04AA5 for ; Wed, 24 Aug 2022 23:09:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230522AbiHXXJw (ORCPT ); Wed, 24 Aug 2022 19:09:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52086 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229452AbiHXXJr (ORCPT ); Wed, 24 Aug 2022 19:09:47 -0400 Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5D4BB384; Wed, 24 Aug 2022 16:09:45 -0700 (PDT) Received: by mail-io1-xd41.google.com with SMTP id i77so14634987ioa.7; Wed, 24 Aug 2022 16:09:45 -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=nfN7vzYKRi5gWBFh5PZpxf6X692fiK9RP6Kfj2aiZUM=; b=gXsf98N6BDtt9J46LjhrosbxASaamCjFBbeZyek2SqtophUFTicppVzRdUF6pTo/yi 0zLbdWXLinOQKmmgDcWfs+3jXCYgvfoj2Xf2Pyn/N2pfJEIFmnWLl04SBRnONOa3KMgJ bxfUpvDwhqz7/GKn/kpOXyICb7Orc2aFIoiXpb8YF5tkCudyIGoII9n8BmtGMaGnooV5 lb8WMQzNiKyjoCnEHEu5TnZYQsTOeqMO8/KAl8+EI6fUIkbWQ3L40cL+ezGYo/KuccUW Ya0i30kpcMMwJNL9lUzwJTUl4BZVHkEMkwRsBoe16ebXmYt3s/7wW5WzcbpI45yMdLkG J1Nw== 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=nfN7vzYKRi5gWBFh5PZpxf6X692fiK9RP6Kfj2aiZUM=; b=I37pCCF4reaO40rXigfpde/vy9J0BpJZEA3PjEPCY+N2N842K0rRvqyrJXTseFaC8v 9ljLilEkJk1ZDpuuFH7FlWSwT5YvOZOhu8CVFmEJ6cqbwTD0zOPC/Wy5s3nJe7O7Oti2 /nmz9x6A0XNUMqKLFwbYvIUa7LXMHsEpXWfK+a1ucg2Zldh9GqAZ8UKNRHxKlmBfjzE6 VCAeQe7CANEB+HH/ZZ5zmhqGIK/iOvvKjoDEs1PXqc5kCphV7qrrcA9S9nk1ICHGUubt wKCyAHv8AAVusjJtzsegCsYD49QjE+Owc5GAO4knLf/BKzyy6avS93IR3PEvoG9u0uXZ 8HQQ== X-Gm-Message-State: ACgBeo3xKCGB8o0pH4FkjxBaXBVmZJmL1b4gawaVVCBmjHvXDa9Qa2pW GHgZ0siNYWIAZO99qwubOXf+hrnCs84RxzvlAQQ= X-Google-Smtp-Source: AA6agR7/EQ2bOEXOIt+jZVy1v1+iH2ECeJoATcDe46DhXzsnPf0ULjy2Q5zdkar8BcZt1tz9mTx/Jm5N7ihAQJbIDm0= X-Received: by 2002:a6b:2ac4:0:b0:688:3a14:2002 with SMTP id q187-20020a6b2ac4000000b006883a142002mr518008ioq.62.1661382584765; Wed, 24 Aug 2022 16:09:44 -0700 (PDT) MIME-Version: 1.0 References: <20220824030031.1013441-1-haoluo@google.com> <20220824030031.1013441-6-haoluo@google.com> In-Reply-To: From: Kumar Kartikeya Dwivedi Date: Thu, 25 Aug 2022 01:09:08 +0200 Message-ID: Subject: Re: [PATCH bpf-next v9 5/5] selftests/bpf: add a selftest for cgroup hierarchical stats collection To: Hao Luo Cc: linux-kernel@vger.kernel.org, bpf@vger.kernel.org, cgroups@vger.kernel.org, netdev@vger.kernel.org, Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , Tejun Heo , Zefan Li , KP Singh , Johannes Weiner , Michal Hocko , John Fastabend , Jiri Olsa , Michal Koutny , Roman Gushchin , David Rientjes , Stanislav Fomichev , Shakeel Butt , Yosry Ahmed Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 25 Aug 2022 at 01:07, Hao Luo wrote: > > On Tue, Aug 23, 2022 at 8:01 PM Hao Luo wrote: > > > > From: Yosry Ahmed > > > > Add a selftest that tests the whole workflow for collecting, > > aggregating (flushing), and displaying cgroup hierarchical stats. > > > > TL;DR: > > - Userspace program creates a cgroup hierarchy and induces memcg reclaim > > in parts of it. > > - 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. > > - Userspace program makes sure the stats are aggregated and read > > correctly. > > > > Detailed explanation: > > - The test loads tracing bpf programs, vmscan_start and vmscan_end, to > > measure the latency of cgroup reclaim. Per-cgroup readings 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). > > > > - Finally, the test creates a cgroup hierarchy and induces memcg reclaim > > in parts of it, and makes sure that the stats collection, aggregation, > > and reading workflow works as expected. > > > > Signed-off-by: Yosry Ahmed > > Signed-off-by: Hao Luo > > --- > > I saw this test failed on CI on s390x [0], because of using kfunc, and > on s390x, "JIT does not support calling kernel function". Is there > anything I can do about it > You can add it to the deny list, like this patch: https://lore.kernel.org/bpf/20220824163906.1186832-1-deso@posteo.net From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kumar Kartikeya Dwivedi Subject: Re: [PATCH bpf-next v9 5/5] selftests/bpf: add a selftest for cgroup hierarchical stats collection Date: Thu, 25 Aug 2022 01:09:08 +0200 Message-ID: References: <20220824030031.1013441-1-haoluo@google.com> <20220824030031.1013441-6-haoluo@google.com> Mime-Version: 1.0 Return-path: 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=nfN7vzYKRi5gWBFh5PZpxf6X692fiK9RP6Kfj2aiZUM=; b=gXsf98N6BDtt9J46LjhrosbxASaamCjFBbeZyek2SqtophUFTicppVzRdUF6pTo/yi 0zLbdWXLinOQKmmgDcWfs+3jXCYgvfoj2Xf2Pyn/N2pfJEIFmnWLl04SBRnONOa3KMgJ bxfUpvDwhqz7/GKn/kpOXyICb7Orc2aFIoiXpb8YF5tkCudyIGoII9n8BmtGMaGnooV5 lb8WMQzNiKyjoCnEHEu5TnZYQsTOeqMO8/KAl8+EI6fUIkbWQ3L40cL+ezGYo/KuccUW Ya0i30kpcMMwJNL9lUzwJTUl4BZVHkEMkwRsBoe16ebXmYt3s/7wW5WzcbpI45yMdLkG J1Nw== In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Hao Luo Cc: linux-kernel@vger.kernel.org, bpf@vger.kernel.org, cgroups@vger.kernel.org, netdev@vger.kernel.org, Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , Tejun Heo , Zefan Li , KP Singh , Johannes Weiner , Michal Hocko , John Fastabend , Jiri Olsa , Michal Koutny , Roman Gushchin , David Rientjes , Stanislav Fomichev , Shakeel Butt , Yosry Ahmed On Thu, 25 Aug 2022 at 01:07, Hao Luo wrote: > > On Tue, Aug 23, 2022 at 8:01 PM Hao Luo wrote: > > > > From: Yosry Ahmed > > > > Add a selftest that tests the whole workflow for collecting, > > aggregating (flushing), and displaying cgroup hierarchical stats. > > > > TL;DR: > > - Userspace program creates a cgroup hierarchy and induces memcg reclaim > > in parts of it. > > - 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. > > - Userspace program makes sure the stats are aggregated and read > > correctly. > > > > Detailed explanation: > > - The test loads tracing bpf programs, vmscan_start and vmscan_end, to > > measure the latency of cgroup reclaim. Per-cgroup readings 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). > > > > - Finally, the test creates a cgroup hierarchy and induces memcg reclaim > > in parts of it, and makes sure that the stats collection, aggregation, > > and reading workflow works as expected. > > > > Signed-off-by: Yosry Ahmed > > Signed-off-by: Hao Luo > > --- > > I saw this test failed on CI on s390x [0], because of using kfunc, and > on s390x, "JIT does not support calling kernel function". Is there > anything I can do about it > You can add it to the deny list, like this patch: https://lore.kernel.org/bpf/20220824163906.1186832-1-deso@posteo.net