On 10/12/21 08:08, toybox-requ...@lists.landley.net wrote:
Message: 1
Date: Thu, 9 Dec 2021 04:16:45 -0600
From: Rob Landley <r...@landley.net>
To: enh <e...@google.com>, toybox <toybox@lists.landley.net>
Subject: Re: [Toybox] more general sched_setattr/sched_getattr
command?
Message-ID: <ada06669-1268-654e-4721-0308c348b...@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@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
------------------------------
End of Toybox Digest, Vol 122, Issue 5
**************************************
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
