Re: [PATCH 0/1] coresched: Manage core scheduling cookies for tasks

[Phil Auld <pauld@redhat.com>]

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
> > 
> 
> -- 

--