Re: [PATCH] xfstests: add a CGROUP configuration option

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]



On 2/17/20 11:38 AM, Brian Foster wrote:
On Fri, Feb 14, 2020 at 03:34:31PM -0500, Josef Bacik wrote:
I want to add some extended statistic gathering for xfstests, but it's
tricky to isolate xfstests from the rest of the host applications.  The
most straightforward way to do this is to run every test inside of it's
own cgroup.  From there we can monitor the activity of tasks in the
specific cgroup using BPF.


I'm curious what kind of info you're looking for from tests..


Latencies. We have all of these tests doing all sorts of interesting things, I want to track operation latencies with code we're actually testing so I can see if I've introduced a performance regression somewhere. Since Facebook's whole fleet is on btrfs I want to make sure I'm only getting information from things being run by xfstests so I can easily go back and hunt down regressions that get introduced. With BPF I can filter on cgroup membership, so I know I'm only recording stats I care about.

The support for this is pretty simple, allow users to specify
CGROUP=/path/to/cgroup.  We will create the path if it doesn't already
exist, and validate we can add things to cgroup.procs.  If we cannot
it'll be disabled, otherwise we will use this when we do _run_seq by
echo'ing the bash pid into cgroup.procs, which will cause any children
to run under that cgroup.


Seems reasonable, but is there any opportunity to combine this with what
we have in common/cgroup2? It's not clear to me if this cares about
cgroup v1 or v2, but perhaps the cgroup2 checks could be built on top of
a generic CGROUP var? I'm also wondering if we'd want to change runtime
behavior purely based on the existence of the path as opposed to some
kind of separate knob (in the event some future test requires the path
for some reason without wanting to enable this mechanism).


Oh I probably should have looked around, yeah we can definitely use this. My initial thought is to just make CGROUP2_PATH exported always, we create /path/to/cgroup2/xfstests and point CGROUP2_PATH at that, and then any tests that use the cgroup2 path for their test will automatically be populated under that global xfstests directory, so I can still capture them with my scripts. Does that sound reasonable? Thanks,

Josef



[Index of Archives]     [Linux Filesystems Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux