[Toybox] more general sched_setattr/sched_getattr command?

[scsijon]

On 10/12/21 08:08, toybox-request at lists.landley.net wrote:
> Message: 1
> Date: Thu, 9 Dec 2021 04:16:45 -0600
> From: Rob Landley <rob at landley.net>
> To: enh <enh at google.com>, toybox <toybox at lists.landley.net>
> Subject: Re: [Toybox] more general sched_setattr/sched_getattr
> 	command?
> Message-ID: <ada06669-1268-654e-4721-0308c348b3cd at landley.net>
> Content-Type: text/plain; charset=utf-8
>
> 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...
BarryK's EasyOS and pflask I recently wrote about i think is one.
>
>> 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
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
>
> ------------------------------
>
> End of Toybox Digest, Vol 122, Issue 5
> **************************************