All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Palethorpe <rpalethorpe@suse.de>
To: ltp@lists.linux.it
Subject: [LTP] [RFC PATCH v2 5/7] docs: Update CGroups API
Date: Tue, 09 Mar 2021 15:46:27 +0000	[thread overview]
Message-ID: <8735x4gwj0.fsf@suse.de> (raw)
In-Reply-To: <YEeMKc9HO9lFv+r7@yuki.lan>

Hello,

Cyril Hrubis <chrubis@suse.cz> writes:

> Hi!
>> +static void setup(void)
>> +{
>> +	tst_cgroup_require(TST_CGROUP_MEMORY, NULL);
>> +	cg = tst_cgroup_get_default();
>> +	SAFE_CGROUP_PRINTF(&cg->cgroup.procs, "%d", getpid());
>> +	SAFE_CGROUP_PRINTF(&cg->memory.max, "%lu", MEMSIZE);
>
> I've been looking at the API for a while and I do not understand why we
> need to create the tst_cgroup_files for each supported controller and
> each node in the hierarchy. Why can't we make this more driver-like? All
> we need to know is the controller type, cgroup version and file we want
> to read/write.
>
> If I were designing the API I would have made these so that they take a
> pointer to a cgroup node, controller type and filename, then the
> printf-like formatting.
>
> So the end result would look like:
>
> 	SAFE_CGROUP_PRINTF(cg, TST_CGROUP_MEMORY, "memory.max", "%lu", MEMSIZE);

If we use V2 naming the controller is always specified in the file
name. So we can just write.

SAFE_CGROUP_PRINTF(cg, "memory.max", ...);

So both you and Li Wang think this is too complex and I wasn't sure, so
I will respin it with a lookup table instead.

>
> Which would be build on the top of:
>
> int tst_cgroup_open(struct tst_cgroup *cg, enum tst_cgroup_ctrl ctrl, const char *fname);
>
> And instead of storing the file structures into the tst_cgroup structure
> we would translate the v2 to v1 on the fly. We would have to open and
> close the files on each printf/scanf but I do not think that it's
> unreasonable given the simplification of the interface.
>
> We would end up with a simple translation tables for different
> controllers instead of the structures that are allocated for each node
> then, such as:
>
> static const struct cgroup_map cgroup_memory_map[] = {
> 	{"memory.usage_in_bytes", "memory.current"},
> 	{"memory.limit_in_bytes", "memory.max"},
> 	{"memory.memsw.usage_in_bytes", "memory.swap.current"},
> 	{"memory.memsw.limitin_bytes", "memory.swap.max"},
> 	{}
> };
>
> Or is there a reason why this cannot be done so?
>
> -- 
> Cyril Hrubis
> chrubis@suse.cz


-- 
Thank you,
Richard.

  reply	other threads:[~2021-03-09 15:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-02 15:25 [LTP] [RFC PATCH v2 0/7] CGroup API rewrite Richard Palethorpe
2021-03-02 15:25 ` [LTP] [RFC PATCH v2 1/7] API: Add safe openat, printfat, readat and unlinkat Richard Palethorpe
2021-03-08  8:37   ` Li Wang
2021-03-02 15:25 ` [LTP] [RFC PATCH v2 2/7] API: Add macro for the container_of trick Richard Palethorpe
2021-03-08  8:39   ` Li Wang
2021-03-02 15:25 ` [LTP] [RFC PATCH v2 3/7] Add new CGroups Core and Item APIs Richard Palethorpe
2021-03-08  9:04   ` Li Wang
2021-03-02 15:25 ` [LTP] [RFC PATCH v2 4/7] Add new CGroups API library tests Richard Palethorpe
2021-03-02 15:25 ` [LTP] [RFC PATCH v2 5/7] docs: Update CGroups API Richard Palethorpe
2021-03-09 14:54   ` Cyril Hrubis
2021-03-09 15:46     ` Richard Palethorpe [this message]
2021-03-02 15:25 ` [LTP] [RFC PATCH v2 6/7] mem: Convert tests to new " Richard Palethorpe
2021-03-02 15:25 ` [LTP] [RFC PATCH v2 7/7] madvise06: Convert " Richard Palethorpe

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=8735x4gwj0.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 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.