[Toybox] more general sched_setattr/sched_getattr command?

[enh]

On Fri, Dec 10, 2021 at 3:46 AM Rob Landley <rob at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20211210/dee52739/attachment-0001.htm>