From: Phil Auld <pauld@redhat.com>
To: Thijs Raymakers <thijs@raymakers.nl>
Cc: kzak@redhat.com, util-linux@vger.kernel.org
Subject: Re: [PATCH 0/1] coresched: Manage core scheduling cookies for tasks
Date: Tue, 26 Mar 2024 16:17:22 -0400 [thread overview]
Message-ID: <20240326201722.GF315070@lorien.usersys.redhat.com> (raw)
In-Reply-To: <20240326201618.GE315070@lorien.usersys.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
> >
>
> --
--
next prev parent reply other threads:[~2024-03-26 20:17 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-16 17:10 [PATCH RFC] coresched: Manage core scheduling cookies for tasks Thijs Raymakers
2024-03-24 20:07 ` Karel Zak
2024-03-26 14:41 ` Phil Auld
2024-03-26 14:45 ` Phil Auld
2024-03-26 17:49 ` [PATCH 0/1] " Thijs Raymakers
2024-03-26 18:13 ` Phil Auld
2024-03-27 12:43 ` [PATCH v2 " Thijs Raymakers
2024-03-27 13:21 ` Phil Auld
2024-03-27 14:18 ` Phil Auld
2024-03-27 15:30 ` [PATCH v3] " Thijs Raymakers
2024-04-01 17:18 ` Thomas Weißschuh
2024-04-04 22:03 ` [PATCH v4] " Thijs Raymakers
2024-04-05 6:26 ` Thomas Weißschuh
2024-04-05 14:14 ` Phil Auld
2024-04-08 21:16 ` [PATCH v5] " Thijs Raymakers
2024-04-09 6:12 ` Thomas Weißschuh
2024-04-09 11:55 ` [PATCH v6] " Thijs Raymakers
2024-04-09 13:44 ` Karel Zak
2024-04-09 14:12 ` Phil Auld
2024-04-10 21:11 ` [PATCH v7] " Thijs Raymakers
2024-04-10 22:15 ` Phil Auld
2024-04-11 11:02 ` [PATCH v8] " Thijs Raymakers
2024-04-11 13:46 ` Phil Auld
2024-04-17 10:31 ` Karel Zak
2024-04-17 11:39 ` [PATCH v9] " Thijs Raymakers
2024-04-23 9:27 ` Karel Zak
2024-04-23 10:19 ` Thomas Weißschuh
2024-04-23 11:12 ` [PATCH v10] " Thijs Raymakers
2024-04-25 15:36 ` [PATCH v11] " Thijs Raymakers
2024-04-25 15:51 ` Thomas Weißschuh
2024-04-25 16:22 ` [PATCH v12] " Thijs Raymakers
2024-04-26 7:59 ` Karel Zak
2024-04-26 18:03 ` Thomas Weißschuh
2024-04-29 8:28 ` Karel Zak
2024-04-17 12:27 ` [PATCH v8] " Phil Auld
2024-03-27 12:43 ` [PATCH v2 1/1] " Thijs Raymakers
2024-03-27 14:09 ` Phil Auld
2024-03-26 19:09 ` [PATCH 0/1] " Phil Auld
2024-03-26 19:26 ` Thijs Raymakers
2024-03-26 20:16 ` Phil Auld
2024-03-26 20:17 ` Phil Auld [this message]
2024-03-26 17:49 ` [PATCH 1/1] " Thijs Raymakers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240326201722.GF315070@lorien.usersys.redhat.com \
--to=pauld@redhat.com \
--cc=kzak@redhat.com \
--cc=thijs@raymakers.nl \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.