All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yosry Ahmed <yosryahmed@google.com>
To: Hao Luo <haoluo@google.com>
Cc: Andrii Nakryiko <andrii@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Mykola Lysenko <mykolal@fb.com>, Song Liu <song@kernel.org>,
	Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@google.com>, Jiri Olsa <jolsa@kernel.org>,
	bpf <bpf@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] selftests/bpf: simplify cgroup_hierarchical_stats selftest
Date: Mon, 29 Aug 2022 18:06:41 -0700	[thread overview]
Message-ID: <CAJD7tkZg2jzDDR6vn5=-TS93Tm3P-YEQ+06KDsjg=Mzkt5LqsA@mail.gmail.com> (raw)
In-Reply-To: <CAJD7tkYKYv+SKhCJs2281==55sALTX_DXifaWPv1w5=xrJjqQA@mail.gmail.com>

On Mon, Aug 29, 2022 at 3:15 PM Yosry Ahmed <yosryahmed@google.com> wrote:
>
> Hi Hao,
>
> Thanks for taking a look!
>
> On Mon, Aug 29, 2022 at 1:08 PM Hao Luo <haoluo@google.com> wrote:
> >
> > On Fri, Aug 26, 2022 at 4:06 PM Yosry Ahmed <yosryahmed@google.com> wrote:
> > >
> > > The cgroup_hierarchical_stats selftest is complicated. It has to be,
> > > because it tests an entire workflow of recording, aggregating, and
> > > dumping cgroup stats. However, some of the complexity is unnecessary.
> > > The test now enables the memory controller in a cgroup hierarchy, invokes
> > > reclaim, measure reclaim time, THEN uses that reclaim time to test the
> > > stats collection and aggregation. We don't need to use such a
> > > complicated stat, as the context in which the stat is collected is
> > > orthogonal.
> > >
> > > Simplify the test by using a simple stat instead of reclaim time, the
> > > total number of times a process has ever entered a cgroup. This makes
> > > the test simpler and removes the dependency on the memory controller and
> > > the memory reclaim interface.
> > >
> > > Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
> > > ---
> >
> > Yosry, please tag the patch with the repo it should be applied on:
> > bpf-next or bpf.
> >
>
> Will do for v2.
>
> > >
> > > When the test failed on Alexei's setup because the memory controller was
> > > not enabled I realized this is an unnecessary dependency for the test,
> > > which inspired this patch :) I am not sure if this prompt a Fixes tag as
> > > the test wasn't broken.
> > >
> > > ---
> > >  .../prog_tests/cgroup_hierarchical_stats.c    | 157 ++++++---------
> > >  .../bpf/progs/cgroup_hierarchical_stats.c     | 181 ++++++------------
> > >  2 files changed, 118 insertions(+), 220 deletions(-)
> > >
> > [...]
> > > diff --git a/tools/testing/selftests/bpf/progs/cgroup_hierarchical_stats.c b/tools/testing/selftests/bpf/progs/cgroup_hierarchical_stats.c
> > > index 8ab4253a1592..c74362854948 100644
> > > --- a/tools/testing/selftests/bpf/progs/cgroup_hierarchical_stats.c
> > > +++ b/tools/testing/selftests/bpf/progs/cgroup_hierarchical_stats.c
> > > @@ -1,7 +1,5 @@
> > >  // SPDX-License-Identifier: GPL-2.0-only
> > >  /*
> > > - * Functions to manage eBPF programs attached to cgroup subsystems
> > > - *
> >
> > Please also add comments here explaining what the programs in this file do.
> >
>
> Will do.
>
> > >   * Copyright 2022 Google LLC.
> > >   */
> > [...]
> > >
> > > -SEC("tp_btf/mm_vmscan_memcg_reclaim_begin")
> > > -int BPF_PROG(vmscan_start, int order, gfp_t gfp_flags)
> > > +SEC("fentry/cgroup_attach_task")
> >
> > Can we select an attachpoint that is more stable? It seems
> > 'cgroup_attach_task' is an internal helper function in cgroup, and its
> > signature can change. I'd prefer using those commonly used tracepoints
> > and EXPORT'ed functions. IMHO their interfaces are more stable.
> >
>
> Will try to find a more stable attach point. Thanks!

Hey Hao,

I couldn't find any suitable stable attach points under kernel/cgroup.
Most tracepoints are created using TRACE_CGROUP_PATH which only
invokes the tracepoint if the trace event is enabled, which I assume
is not something we can rely on. Otherwise, there is only
trace_cgroup_setup_root() and trace_cgroup_destroy_root() which are
irrelevant here. A lot of EXPORT'ed functions are not called in the
kernel, or cannot be invoked from userspace (the test) in a
straightforward way. Even if they did, future changes to such code
paths can also change in the future, so I don't think there is really
a way to guarantee that future changes don't break the test.

Let me know what you think.

>
> > > +int BPF_PROG(counter, struct cgroup *dst_cgrp, struct task_struct *leader,
> > > +            bool threadgroup)
> > >  {
> > > -       struct task_struct *task = bpf_get_current_task_btf();
> > > -       __u64 *start_time_ptr;
> > > -
> > > -       start_time_ptr = bpf_task_storage_get(&vmscan_start_time, task, 0,
> > > -                                             BPF_LOCAL_STORAGE_GET_F_CREATE);
> > > -       if (start_time_ptr)
> > > -               *start_time_ptr = bpf_ktime_get_ns();
> > > -       return 0;
> > > -}
> > [...]
> > >  }
> > > --
> > > 2.37.2.672.g94769d06f0-goog
> > >

  reply	other threads:[~2022-08-30  1:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-26 23:06 [PATCH] selftests/bpf: simplify cgroup_hierarchical_stats selftest Yosry Ahmed
2022-08-28 22:48 ` KP Singh
2022-08-29 17:24   ` Yosry Ahmed
2022-08-29 20:08 ` Hao Luo
2022-08-29 22:15   ` Yosry Ahmed
2022-08-30  1:06     ` Yosry Ahmed [this message]
2022-08-30  1:42       ` Hao Luo
2022-08-30  1:50         ` Yosry Ahmed
2022-09-06 21:35           ` Yosry Ahmed
2022-09-10  0:49             ` Andrii Nakryiko
2022-09-19 15:24               ` 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='CAJD7tkZg2jzDDR6vn5=-TS93Tm3P-YEQ+06KDsjg=Mzkt5LqsA@mail.gmail.com' \
    --to=yosryahmed@google.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=mykolal@fb.com \
    --cc=sdf@google.com \
    --cc=song@kernel.org \
    --cc=yhs@fb.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: link
Be 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.