<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 9, 2021 at 2:16 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 12/7/21 2:27 PM, enh via Toybox wrote:<br>
> is there an existing general sched_setattr/sched_getattr command somewhere that<br>
> we can copy? we have chrt/nice/taskset for various subsets, and i think that<br>
> _between_ them they already cover everything that sched_setattr(2) can do --<br>
> policy/reset-on-fork/nice/priority -- except for 5.3+'s "task utilization<br>
> attributes", sched_util_min/sched_util_max?<br>
> (see <a href="https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/sched/types.h#L86" rel="noreferrer" target="_blank">https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/sched/types.h#L86</a><br>
> <<a href="https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/sched/types.h#L86" rel="noreferrer" target="_blank">https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/sched/types.h#L86</a>><br>
> for those, since they're not in the man7 man pages yet.)<br>
<br>
Kernel commit a509a7cd7974 June 2019. Not exactly 7 year time horizon, but if<br>
there's interest... Let's see:<br>
<br>
include/linux/sched.h:# define SCHED_CAPACITY_SCALE (1L << SCHED_CAPACITY_SHIFT)<br>
<br>
Which is gratuitously wrappped as...<br>
<br>
# define SCHED_CAPACITY_SHIFT           SCHED_FIXEDPOINT_SHIFT<br>
<br>
Which is...<br>
<br>
# define SCHED_FIXEDPOINT_SHIFT         10<br>
<br>
Ok, so the scale is 0-1023. And it's hardwired to be the same on all targets, so<br>
of course they made it a #define in a header so they can change it and break<br>
binary compatibility in future. Lovely.<br>
<br>
> i'm asking because there are Android folks who're using the<br>
> sched_util_min/sched_util_max stuff (that they seem to call "uclamp") who would<br>
<br>
Googling for uclamp...<br>
<br>
<a href="https://github.com/darkhz/uclamp/wiki/UClamp" rel="noreferrer" target="_blank">https://github.com/darkhz/uclamp/wiki/UClamp</a><br>
<br>
Does not appear to be a tool, his tree has backports of the kernel plumbing to<br>
various older kernels. And he thinks the range is 0-1024. And that there's a<br>
/dev/cpuset which my laptop hasn't got. (Why you can request a minimum<br>
utilization of 0 I couldn't tell you, of course. Recipe for deadlock?)<br></blockquote><div><br></div><div>someone sent me <a href="https://man7.org/linux/man-pages/man1/uclampset.1.html">https://man7.org/linux/man-pages/man1/uclampset.1.html</a> 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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> like a command-line interface (and currently have their own random thing), but<br>
> aren't able to point to any existing practice.<br>
<br>
I can add a new command. Or I can add it as an option to an existing command.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On a side note, I recently did a patch to add -n to taskset (so taskset -n 3<br>
would restrict to 3 randomly selected available processors, rather than you<br>
having to work out a bitmask), but I culled it for the release because I hit the<br>
crazy historical command line option parsing of taskset: it turns out that -p<br>
doesn't take an argument:<br>
<br>
  <a href="https://landley.net/notes-2021.html#22-10-2021" rel="noreferrer" target="_blank">https://landley.net/notes-2021.html#22-10-2021</a><br>
<br>
  "taskset -p 7 1" sets PID 1 to mask 7, not the other way around.<br></blockquote><div><br></div><div>on the bright side, despite the similar name, uclampset doesn't make that mistake :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
And of course for EXTRA crazy:<br>
<br>
  $ taskset -c -p 1 $$<br>
  pid 12855's current affinity list: 0-3<br>
  pid 12855's new affinity list: 1<br>
<br>
My naive addition of "taskset -n 3" had -n taking an argument, but that's not<br>
how Robert Love wrote taskset.<br>
<br>
(The other option I'd added was -b so you can feed it a binary mask, ala<br>
"taskset -b 1011 eat_cpu", because when you're making a mask that's what you're<br>
actually doing. But I yanked that out at the same time because I'm too disgusted<br>
to touch this command's argument parsing logic. I should go back and add -c...)<br>
<br>
tl;dr chrt -u and -U aren't used yet. :)<br>
<br>
> i'm wondering whether yet another special case makes sense, or we should try to<br>
> have a more generic "schedattr" command. and, even more interestingly, whether<br>
> there's any existing practice on other systems that we should be looking at?<br>
<br>
No existing practice I'm aware of, but the kernel feature is only 2 years old.<br>
The kernel clique is so insular I'm surprised anybody else noticed its existence<br>
yet.<br></blockquote><div><br></div><div>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...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I've encountered container-ish commands with 8 gazillion command line options<br>
you can set, uid and nice level and cpu mask and realtime policy and namespaces<br>
and unshare so on all in one go. Don't remember where off the top of my head,<br>
but I have a todo item to look into that...<br>
<br>
> alternatively, although these new options don't seem like a *great* fit for<br>
> chrt, it would probably be doable to add them as something like long-opt-only<br>
> `--util-min X` and `--util-max X`? we could just make the current "no PRIORITY"<br>
> not an error if you supplied one/both of those? (Android's current tool always<br>
> takes both min and max, which is a bit awkward as an option.)<br>
<br>
Sigh. If you must, but I really dislike --longopts without a corresponding short<br>
option because that's not how unix works. (I believe that style originated with<br>
gnu.) I'm aware short option conflict is a thing, but "I depend on this longopt<br>
that another implementation doesn't have" is just as much of a thing: can't swap<br>
out implementations either way.<br>
<br>
Rob<br>
</blockquote></div></div>