public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Richard Palethorpe <rpalethorpe@suse.de>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 4/6] API/cgroups: Add cpu controller
Date: Thu, 20 May 2021 09:35:35 +0100	[thread overview]
Message-ID: <877djtls4o.fsf@suse.de> (raw)
In-Reply-To: <YKT27nlItfECLuYw@yuki>

Hello,

Cyril Hrubis <chrubis@suse.cz> writes:

> Hi!
>>  lib/tst_cgroup.c | 18 +++++++++++++++++-
>>  1 file changed, 17 insertions(+), 1 deletion(-)
>> 
>> diff --git a/lib/tst_cgroup.c b/lib/tst_cgroup.c
>> index 54636fd7e..da177a1ad 100644
>> --- a/lib/tst_cgroup.c
>> +++ b/lib/tst_cgroup.c
>> @@ -82,7 +82,8 @@ struct cgroup_root {
>>  /* Controller sub-systems */
>>  enum cgroup_ctrl_indx {
>>  	CTRL_MEMORY = 1,
>> -	CTRL_CPUSET = 2,
>> +	CTRL_CPU,
>> +	CTRL_CPUSET,
>>  };
>>  #define CTRLS_MAX CTRL_CPUSET
>>  
>> @@ -162,6 +163,18 @@ static const files_t memory_ctrl_files = {
>>  	{ }
>>  };
>>  
>> +static const files_t cpu_ctrl_files = {
>> +	/* The V1 quota and period files were combined in the V2 max
>> +	 * file. The quota is in the first column and if we just print
>> +	 * a single value to the file, it will be treated as the
>> +	 * quota. To get or set the period we need to branch on the
>> +	 * API version.
>> +	 */
>
> I wonder if this is worth a helper function, something as:
>
> #define SAFE_CGROUP_CPU_SET_MAX(cg, quota_us, period_us) \
> 	tst_cgroup_cpu_set_max(__FILE__, __LINENO__, cg, quota_us, period_us)
>
> void tst_cgroup_cpu_set_max(const char *const file, const int lineno,
>                             const struct tst_cgroup_group *const cg,
>                             unsigned int quota_us, unsigned int period_us);
>
> #define SAFE_CGROUP_CPU_GET_MAX(cg, quota_us, period_us) \
> 	tst_cgroup_cpu_get_max(__FILE__, __LINENO__, cg, quota_us, period_us)
>
> void tst_cgroup_cpu_get_max(const char *const file, const int lineno,
>                             const struct tst_cgroup_group *const cg,
>                             unsigned int *quota_us, unsigned int *period_us);
>
> I guess that if we are going to add more tests we would end up with such
> functions somewhere anyways.

Yes, when we have more tests. Because there is an alternative that we
add a mapping/filter layer to transform V2 writes into V1 writes. e.g.

SAFE_CGROUP_PRINTF(cg, "cpu.max", "%d %d", "50 100");

When done on V1 it will write to a buffer with sprintf and then split
that into two writes to the V1 files.

This is much more complicated for this case, but there are hundreds of
these knobs. In some cases we just need to convert a string to an
integer e.g. "max" => "-1" or whatever memory.max takes.

In most cases it will just be a case of sprintf into a buffer and then
do something with that.

I can think of problems with both approaches. :-)

-- 
Thank you,
Richard.

  reply	other threads:[~2021-05-20  8:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-13 15:21 [LTP] [PATCH 0/6] cfs_bandwidth01 and CGroup API Richard Palethorpe
2021-05-13 15:21 ` [LTP] [PATCH 1/6] API/cgroups: Allow fetching of CGroup name Richard Palethorpe
2021-05-19 11:14   ` Cyril Hrubis
2021-05-13 15:21 ` [LTP] [PATCH 2/6] API/cgroups: Remove obsolete function in API Richard Palethorpe
2021-05-19 11:15   ` Cyril Hrubis
2021-05-13 15:21 ` [LTP] [PATCH 3/6] API/cgroups: Check for unknown controller name Richard Palethorpe
2021-05-19 11:20   ` Cyril Hrubis
2021-05-20  8:13     ` Richard Palethorpe
2021-05-13 15:21 ` [LTP] [PATCH 4/6] API/cgroups: Add cpu controller Richard Palethorpe
2021-05-19 11:30   ` Cyril Hrubis
2021-05-20  8:35     ` Richard Palethorpe [this message]
2021-05-13 15:21 ` [LTP] [PATCH 5/6] API/cgroups: Auto add controllers to subtree_control in new subgroup Richard Palethorpe
2021-05-19 11:41   ` Cyril Hrubis
2021-05-20  8:40     ` Richard Palethorpe
2021-05-13 15:21 ` [LTP] [PATCH 6/6] sched/cgroup: Add cfs_bandwidth01 Richard Palethorpe
2021-05-19 11:51   ` Cyril Hrubis
2021-05-20  8:10     ` Cyril Hrubis
2021-05-20  8:50     ` Richard Palethorpe
2021-05-21  9:29       ` Richard Palethorpe
2021-05-25  9:06         ` Cyril Hrubis

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=877djtls4o.fsf@suse.de \
    --to=rpalethorpe@suse.de \
    --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