[Toybox] more general sched_setattr/sched_getattr command?

[Rob Landley]

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...

"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?

>     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?)

*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