<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 10, 2021 at 3:46 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/9/21 7:35 PM, enh wrote:> someone sent<br>
me <a href="https://man7.org/linux/man-pages/man1/uclampset.1.html" rel="noreferrer" target="_blank">https://man7.org/linux/man-pages/man1/uclampset.1.html</a><br>
> <<a href="https://man7.org/linux/man-pages/man1/uclampset.1.html" rel="noreferrer" target="_blank">https://man7.org/linux/man-pages/man1/uclampset.1.html</a>> which seems to be the<br>
> util-linux offering. it certainly looks better than the Android home-grown<br>
> thing, so i've sent a patch with a toybox implementation.<br>
<br>
You call uclampset to get the value? Not just "uclamp"? The thing that can both<br>
get and set has "set" in the name? Ok then...<br></blockquote><div><br></div><div>i refer the right honourable gentleman to my previous answer: "that's what taskset did, and i assume they were copying that".</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">
"Only schedutil cpufreq governor understands handling util clamp hints at the<br>
time of writing. Consult your kernel docs for further info about other cpufreq<br>
governors support."<br>
<br>
It's not quite as user-friendly as "git", but about on par with what you expect<br>
kernel developers to emit into userspace. Hysterical raisins, compatibility with<br>
the existing insanity...<br>
<br>
>     > 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>
> <br>
> aye, the question was which made most sense if we had to tread new ground :-)<br>
> but luckily there is actually precedent so we can save ourselves the worry.<br>
<br>
config UCLAMPSET<br>
  bool "uclampset"<br>
  default n<br>
  help<br>
    usage: uclampset [-m MIN] [-M MAX] {-p PID | COMMAND...}<br>
<br>
    Set or query process utilization limits. Values are from 0-1024,<br>
    or -1 to reset to system default. With no arguments, prints current.<br>
<br>
    -m MIN      Reserve at least this much CPU utilization for task<br>
    -M MAX      Limit task to at most this much CPU utilization<br>
<br>
Whoever wrote that man page: who hurt you?<br></blockquote><div><br></div><div>in their defense, i don't think they're a native english speaker, and at least they wrote _something_. i've seen worse. (though it did genuinely leave me quite confused about how arm-specific this stuff is/what exactly big.LITTLE has to do with it.)</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>
>     <<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>
> <br>
> on the bright side, despite the similar name, uclampset doesn't make that<br>
> mistake :-)<br>
<br>
Thank goodness.<br>
<br>
>     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<br>
>     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>
> <br>
> i think the Android kernel folks might have been involved? if not, they're<br>
> certainly at the bleeding edge of having to deal with systems where not all<br>
> cores are the same...<br>
<br>
The easy way to find out about a new feature in the kernel is to have submitted<br>
it, yes.<br>
<br>
Could you ask them what uclamp_validate() in kernel/sched/core.c is trying to<br>
do? It seems like if you've set container limits for the largest or smallest<br>
allowed uclamp values (like that wiki page was going on about). then it checks<br>
THOSE instead of the ones provided by the user to see if they cross. Overwrites<br>
the ones provided by the user entirely, and doesn't check them. So I THINK if I<br>
set the container min limit to 1 and the container max limit to 1023, I could<br>
then have a process within the container request a min of 1000 and a max of 100<br>
and it would pass this function? (Or am I misreading it?)<br></blockquote><div><br></div><div>i must be misreading it too, because i don't even know which lines you're referring to, unless we were looking at different versions... (<a href="https://elixir.bootlin.com/linux/latest/source/kernel/sched/core.c#L1780">https://elixir.bootlin.com/linux/latest/source/kernel/sched/core.c#L1780</a>)</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">
*shrug* Probably still works fine, I just don't understand what this function is<br>
FOR in that case...<br>
<br>
Ah, I see you've sent an implementation already. (I was halfway through writing<br>
one.) Lemme apply that and then see what if anything of mine still goes in that...<br>
<br>
Rob<br>
</blockquote></div></div>