On Thu, Dec 9, 2021 at 2:16 AM Rob Landley <[email protected]> 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 >
_______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
