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.
next prev parent 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.