[Toybox] more general sched_setattr/sched_getattr command?

[enh]

On Thu, Dec 9, 2021 at 2:16 AM Rob Landley <rob at landley.net> wrote:

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

someone sent me https://man7.org/linux/man-pages/man1/uclampset.1.html
which seems to be the util-linux offering. it certainly looks better than
the Android home-grown thing, so i've sent a patch with a toybox
implementation.


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

aye, the question was which made most sense if we had to tread new ground
:-) but luckily there is actually precedent so we can save ourselves the
worry.


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

on the bright side, despite the similar name, uclampset doesn't make that
mistake :-)


> 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 think the Android kernel folks might have been involved? if not, they're
certainly at the bleeding edge of having to deal with systems where not all
cores are the same...


> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20211209/820efa02/attachment-0001.htm>