On Mon, Sep 30, 2024 at 02:07:22PM GMT, Joshua Hahn <joshua.hahnjy@xxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
