On Mon, Sep 30, 2024 at 02:07:22PM GMT, Joshua Hahn joshua.hahnjy@gmail.com wrote:
The reason I used a fork in the testing is so that I could isolate the niced portion of the test to only the CPU hog. If I were to nice(1) --> cg_hog() in a single process without forking, this would mean that the cleanup portion of the test would also be run as a niced process,
The cleanup runs in a parent process and nice is called after fork in a child in those considered cases (at least that's what I meant).
contributing to the stat and potentially dirtying the value (which is tested for accuracy via `values_close`).
Yes, a test that randomly fails (false negative) is a nuisance. One fork is needed, the second doesn't divide different priority tasks.
What do you think?
My motivation comes from debugging cgroup selftests when strace is quite useful and your implementation adds the unnecessary fork which makes the strace (slightly) less readable.
Do you think that this increase in granularity / accuracy is worth the increase in code complexity? I do agree that it would be much easier to read if there was no fork.
I think both changes (no cg_run or cpu_hog_func_param extension) could be reasonably small changes (existing usages of cpu_hog_func_param extension would default to zero nice, so the actual change would only be in hog_cpus_timed()).
Alternatively, I can add a new parameter to cpu_hog_func_param that takes in a nice value. For this however, I am afraid of changing the function signature of existing utility functions, since it would mean breaking support for older functions or others currently working on this.
The function is internal to the cgroup selftests and others can rebase, so it doesn't have to stick to a particular signature.
HTH, Michal