Linux Test Project
 help / color / mirror / Atom feed
From: Richard Palethorpe <rpalethorpe@suse.de>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 2/2] cgroups: Add first IO controller test
Date: Mon, 28 Mar 2022 15:40:56 +0100	[thread overview]
Message-ID: <87k0cem7fs.fsf@suse.de> (raw)
In-Reply-To: <YjtfTHjUHeHvSTgG@yuki>

Hello,

>> +
>> +		tst_res(TPASS, "Found %u:%u in io.stat", dev_major, dev_minor);
>> +		TST_EXP_EXPR(rbytes > st_rbytes, "(rbytes=%lu) > (st_rbytes=%lu)", rbytes, st_rbytes);
>> +		TST_EXP_EXPR(wbytes > st_wbytes, "(wbytes=%lu) > (st_wbytes=%lu)", wbytes, st_wbytes);
>> +		TST_EXP_EXPR(rios > st_rios, "(rios=%lu) > (st_rios=%lu)", rios, st_rios);
>> +		TST_EXP_EXPR(wios > st_wios, "(wios=%lu) > (st_wios=%lu)", wios, st_wios);
>
> So we only test here that the counters are updated, that sounds fine for
> a simple test.
>
> Do you plan to try anything for io.max? Maybe something as basic as
> running two concurent processes with very different limits and checking
> that the more limited process transfer less bytes per unit of time?

Yes, although maybe not immediately. In the case of io.max this should
not even require comparing concurrent processes as the limits are simply the
absolute number of bytes or iops performed per second by a particular
group. So we can just set them to a very low value and see that reading
or writing takes longer than when unlimited.

io.cost.qos is more complicated because limits are a proportion of the
overall sibling activity.

>
>> +		goto out;
>> +	}
>
> We do have two very similar copies of this parsing code, maybe we should
> put that into a function, and pack the parameters into a structure o
> avoid copy&paste like this. e.g.
>
> struct iostats {
> 	unsigned long st_rbytes;
> 	unsigned long st_wbytes;
> 	unsigned long st_rios;
> 	unsigned long st_wios;
> };
>
> static int read_iostats(const char *stats,
>                         unsigned int dev_min, unsigned int dev_maj,
> 			struct iostats *iostats);
>

+1

>
>> +	tst_res(TINFO, "io.stat:\n%s", buf);
>> +	tst_res(TFAIL, "Did not find %u:%u in io.stat", dev_major, dev_minor);
>> +out:
>> +	free(buf);
>> +	SAFE_CLOSE(fd);
>> +	SAFE_UNLINK("mnt/dat");
>> +}
>> +
>> +static void setup(void)
>> +{
>> +	char buf[PATH_MAX] = { 0 };
>> +	char *path = SAFE_GETCWD(buf, PATH_MAX - sizeof("mnt") - 1);
>> +	struct mntent *mnt;
>> +	FILE *mntf = setmntent("/proc/self/mounts", "r");
>> +	struct stat st;
>> +
>> +	strcpy(path + strlen(path), "/mnt");
>> +
>> +	if (!mntf) {
>> +		tst_brk(TBROK | TERRNO, "Can't open /proc/self/mounts");
>> +		return;
>> +	}
>> +
>> +	mnt = getmntent(mntf);
>> +	if (!mnt) {
>> +		tst_brk(TBROK | TERRNO, "Can't read mounts or no mounts?");
>> +		return;
>> +	}
>> +
>> +	do {
>> +		if (strcmp(mnt->mnt_dir, path))
>> +			continue;
>> +
>> +		SAFE_STAT(mnt->mnt_fsname, &st);
>> +		dev_major = major(st.st_rdev);
>> +		dev_minor = minor(st.st_rdev);
>> +
>> +		return;
>> +
>> +	} while ((mnt = getmntent(mntf)));
>
> I guess that this should probably go to the test library. We already
> have tst_find_backding_dev() in there which is doing something a bit
> similar. Looking at the code what we do here is to translate a
> mountpoint into a device so it may be something as:
>
> int tst_find_dev_by_mntpoint()

OK, I wasn't sure if to replace tst_find_backing_dev() which doesn't do
what the name suggests to me. The actual device it returns will be some
anonymous virtual block device in many cases. If it is btrfs, then the
"backing device" is probably a real device not an anonymous device
created for the subpartion. OTOH maybe this is what was intended.

>
>> +	tst_brk(TBROK, "Could not find mount device");
>> +}
>> +
>> +static struct tst_test test = {
>> +	.test_all = run,
>> +	.setup = setup,
>> +	.needs_device = 1,
>> +	.mntpoint = "mnt",
>> +	.mount_device = 1,
>> +	.all_filesystems = 1,
>> +	.skip_filesystems = (const char *const[]){ "ntfs", "tmpfs", NULL },
>> +	.needs_cgroup_ver = TST_CG_V2,
>> +	.needs_cgroup_ctrls = (const char *const[]){ "io", NULL },
>> +};
>> -- 
>> 2.35.1
>> 
>> 
>> -- 
>> Mailing list info: https://lists.linux.it/listinfo/ltp


-- 
Thank you,
Richard.

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

      reply	other threads:[~2022-03-28 15:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-15 13:41 [LTP] [PATCH 1/2] API/cgroup: Add io controller Richard Palethorpe via ltp
2022-03-15 13:41 ` [LTP] [PATCH 2/2] cgroups: Add first IO controller test Richard Palethorpe via ltp
2022-03-23 17:56   ` Cyril Hrubis
2022-03-28 14:40     ` Richard Palethorpe [this message]

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=87k0cem7fs.fsf@suse.de \
    --to=rpalethorpe@suse.de \
    --cc=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox