On Tue, Mar 26, 2024 at 04:16:23PM -0400 Phil Auld wrote: > On Tue, Mar 26, 2024 at 08:26:23PM +0100 Thijs Raymakers wrote: > > 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 > > ... > > Hhm, I'd prefer the no argument case to be a noop. > > But okay, I was missing something :) This is where some output might > have helped though ... > > So "-n/--new" creates a new cookie and so does "". Just one on an existing task > and one on the exec'd task. Seems inconsistent, no? > > > > > By default, it will spawn the provided program with a new core > > scheduling cookie. > > > > See above about default. But maybe that's just my taste. > > Since you have expplicit commands to do things why not just make --get be > the default no command one? So coresched -p 1234 just reports the cookie > of pid 1234 or corsched ls just reports (in this case the meaningless) cookie > of the exec'd ls command. > > The use the -n and friends as an action operation to create/copy etc. > > > > 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). > > Yes, true. But it's sometimes nice to see that the command you ran did > something, > > > But anyway, that's more of my 2 cents. I'll try it again with new > knowledge. > Btw, did you try coreset to see if it does what you need? Cheers, Phil > > Cheers, > Phil > > > > > 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 > > > > -- --
