[Toybox] more general sched_setattr/sched_getattr command?

[Rob Landley]

On 12/7/21 2:27 PM, enh via Toybox wrote:
> is there an existing general sched_setattr/sched_getattr command somewhere that
> we can copy? we have chrt/nice/taskset for various subsets, and i think that
> _between_ them they already cover everything that sched_setattr(2) can do --
> policy/reset-on-fork/nice/priority -- except for 5.3+'s "task utilization
> attributes", sched_util_min/sched_util_max?
> (see https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/sched/types.h#L86
> <https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/sched/types.h#L86>
> for those, since they're not in the man7 man pages yet.)

Kernel commit a509a7cd7974 June 2019. Not exactly 7 year time horizon, but if
there's interest... Let's see:

include/linux/sched.h:# define SCHED_CAPACITY_SCALE (1L << SCHED_CAPACITY_SHIFT)

Which is gratuitously wrappped as...

# define SCHED_CAPACITY_SHIFT           SCHED_FIXEDPOINT_SHIFT

Which is...

# define SCHED_FIXEDPOINT_SHIFT         10

Ok, so the scale is 0-1023. And it's hardwired to be the same on all targets, so
of course they made it a #define in a header so they can change it and break
binary compatibility in future. Lovely.

> i'm asking because there are Android folks who're using the
> sched_util_min/sched_util_max stuff (that they seem to call "uclamp") who would

Googling for uclamp...

https://github.com/darkhz/uclamp/wiki/UClamp

Does not appear to be a tool, his tree has backports of the kernel plumbing to
various older kernels. And he thinks the range is 0-1024. And that there's a
/dev/cpuset which my laptop hasn't got. (Why you can request a minimum
utilization of 0 I couldn't tell you, of course. Recipe for deadlock?)

> like a command-line interface (and currently have their own random thing), but
> aren't able to point to any existing practice.

I can add a new command. Or I can add it as an option to an existing command.

On a side note, I recently did a patch to add -n to taskset (so taskset -n 3
would restrict to 3 randomly selected available processors, rather than you
having to work out a bitmask), but I culled it for the release because I hit the
crazy historical command line option parsing of taskset: it turns out that -p
doesn't take an argument:

  https://landley.net/notes-2021.html#22-10-2021

  "taskset -p 7 1" sets PID 1 to mask 7, not the other way around.

And of course for EXTRA crazy:

  $ taskset -c -p 1 $$
  pid 12855's current affinity list: 0-3
  pid 12855's new affinity list: 1

My naive addition of "taskset -n 3" had -n taking an argument, but that's not
how Robert Love wrote taskset.

(The other option I'd added was -b so you can feed it a binary mask, ala
"taskset -b 1011 eat_cpu", because when you're making a mask that's what you're
actually doing. But I yanked that out at the same time because I'm too disgusted
to touch this command's argument parsing logic. I should go back and add -c...)

tl;dr chrt -u and -U aren't used yet. :)

> i'm wondering whether yet another special case makes sense, or we should try to
> have a more generic "schedattr" command. and, even more interestingly, whether
> there's any existing practice on other systems that we should be looking at?

No existing practice I'm aware of, but the kernel feature is only 2 years old.
The kernel clique is so insular I'm surprised anybody else noticed its existence
yet.

I've encountered container-ish commands with 8 gazillion command line options
you can set, uid and nice level and cpu mask and realtime policy and namespaces
and unshare so on all in one go. Don't remember where off the top of my head,
but I have a todo item to look into that...

> alternatively, although these new options don't seem like a *great* fit for
> chrt, it would probably be doable to add them as something like long-opt-only
> `--util-min X` and `--util-max X`? we could just make the current "no PRIORITY"
> not an error if you supplied one/both of those? (Android's current tool always
> takes both min and max, which is a bit awkward as an option.)

Sigh. If you must, but I really dislike --longopts without a corresponding short
option because that's not how unix works. (I believe that style originated with
gnu.) I'm aware short option conflict is a thing, but "I depend on this longopt
that another implementation doesn't have" is just as much of a thing: can't swap
out implementations either way.

Rob