On Fri, Dec 10, 2021 at 3:46 AM Rob Landley <r...@landley.net> wrote:
> On 12/9/21 7:35 PM, enh wrote:> someone sent > me https://man7.org/linux/man-pages/man1/uclampset.1.html > > <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. > > You call uclampset to get the value? Not just "uclamp"? The thing that can > both > get and set has "set" in the name? Ok then... > i refer the right honourable gentleman to my previous answer: "that's what taskset did, and i assume they were copying that". > "Only schedutil cpufreq governor understands handling util clamp hints at > the > time of writing. Consult your kernel docs for further info about other > cpufreq > governors support." > > It's not quite as user-friendly as "git", but about on par with what you > expect > kernel developers to emit into userspace. Hysterical raisins, > compatibility with > the existing insanity... > > > > 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. > > config UCLAMPSET > bool "uclampset" > default n > help > usage: uclampset [-m MIN] [-M MAX] {-p PID | COMMAND...} > > Set or query process utilization limits. Values are from 0-1024, > or -1 to reset to system default. With no arguments, prints current. > > -m MIN Reserve at least this much CPU utilization for task > -M MAX Limit task to at most this much CPU utilization > > Whoever wrote that man page: who hurt you? > 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.) > > 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 > > <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 :-) > > Thank goodness. > > > 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... > > The easy way to find out about a new feature in the kernel is to have > submitted > it, yes. > > Could you ask them what uclamp_validate() in kernel/sched/core.c is trying > to > do? It seems like if you've set container limits for the largest or > smallest > allowed uclamp values (like that wiki page was going on about). then it > checks > THOSE instead of the ones provided by the user to see if they cross. > Overwrites > the ones provided by the user entirely, and doesn't check them. So I THINK > if I > set the container min limit to 1 and the container max limit to 1023, I > could > then have a process within the container request a min of 1000 and a max > of 100 > and it would pass this function? (Or am I misreading it?) > 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... ( https://elixir.bootlin.com/linux/latest/source/kernel/sched/core.c#L1780) > *shrug* Probably still works fine, I just don't understand what this > function is > FOR in that case... > > Ah, I see you've sent an implementation already. (I was halfway through > writing > one.) Lemme apply that and then see what if anything of mine still goes in > that... > > Rob >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net