Op 26-03-2024 om 20:09 schreef Phil Auld: > I tried this version out and it doesn't work for me. One of the > basic use cases of a wrapper like this is to run a command with > a new cookie (say starting a container or something). > > Coresched requires a pid to do that: > # ./coresched -n ls > coresched: Failed to parse PID for -n/--new: 'ls' > > With my coreset utility it does work and gives some information about what > it did: > > # coreset -n ls > pid 20860's current cookie: 0x0 > pid 20860's new cookie: 0xa9fcfbf1 > ABOUT-NLS chrt configure ionice libsmartcols Makefile.in > ... > > Did I miss something? I think this will be one of the primary use cases for > this utility. Hi Phil, The following command works # ./coresched ls chrt.1 chrt.1.deps coresched.1.adoc coresched.o ionice.1.adoc ... By default, it will spawn the provided program with a new core scheduling cookie. This command # ./coresched -n 123 is to assign a new core scheduling cookie to PID 123. The commands don't show what the current and/or new cookie is, because that is of limited utility in my opinion (and --get also does this). You can only use it to check if two programs have the same cookie. An error message will be printed and the exit code will be set if it doesn't succeed. Otherwise, if the program succeeds then it won't write anything to stderr/stdout. Thijs
