[Toybox] [PATCH] Add uclampset(1).

[Rob Landley]

On 12/10/21 1:53 PM, enh wrote:
> On Fri, Dec 10, 2021 at 6:52 AM Rob Landley <rob at landley.net
> <mailto:rob at landley.net>> wrote:
> 
>     On 12/9/21 7:31 PM, enh via Toybox wrote:
>     > No standard, but part of util-linux.
> 
>     Don't default y in pending.
> 
> yeah, sorry. i realized that after i'd gone to bed. at least i'm consistent ...
> i *always* make that mistake.

Eh, should be a fairly fast promotion, I just need to get it to _work_ first. :)

>     USE_TASKSET(NEWTOY(uclampset)) doesn't match.
> 
> d'oh. _that's_ a new mistake though!

I usually do it with "USE_HELLO" so have learned to check. :)

>     Does this require root?
>  
> as you can tell from the previous mistake, i took taskset as a basis for this.
> it seemed plausible to me that if taskset needed STAYROOT (which i assume is
> what you're asking about here), this would too? but i've no idea.

I suspect taskset doesn't either. It needs it to set the mask of processes you
don't own, but you should legitimately be root for that?

(P.S. The kernel says "Invalid argument" for an attempt to set taskset to 0.
That's one of the things I need to be sure to check about this new plumbing...)

>     >From a UI perspective, do we ever _not_ want -a?
> 
> i wondered that too, but this is what the util-linux one does. (which is
> presumably just because that's what taskset does. so -- like me with `default y`
> at least they're _consistent_.)

Complicates the code, but simplifies the help text. Hmmm...

I suppose I could move -a to the end? There's tension between "options in
alphabetical order so you can find them" and "options in some sort of coherent
order where they make SENSE".

You'll note that find.c errs ENTIRELY towards the second, but you've pretty much
GOTTA collate name/iname path/ipath user/nouser group/nogroup, true/false,
depth/maxdepth/mindepth... Plus you'll notice it's totally cheating by having
the "-option  explanation" indentation be WAY different on the left (16 chars
after the dash) side than on the right side (11 chars). I kind of want to
collate prune/xdev/empty/quit, but... hmmm, maybe options with no arguments on
the right and ones with arguments on the left? Except I haven't got an equal
number of types. (Plus those last two lines just go all the way across because
there's too much to explain, and newerXY would be right under -newer...)

Anyway, this kinda polishing thing can eat All The Time if I let it. :)

>     Sigh. It's HARD to come up with a good terse description of -R.
> 
> yeah, as you can see, i gave up: "you're going to want to read a man page ---
> here's what you should search for" was all i was going for there.

    -R  Reset child processes to default values on fork

>     $ grep syscall\.h toys/*/*.c
>     toys/other/chrt.c:#include <sys/syscall.h>
>     toys/other/insmod.c:#include <sys/syscall.h>
>     toys/other/ionice.c:#include <sys/syscall.h>
>     toys/other/nsenter.c:#include <sys/syscall.h>
>     toys/other/pivot_root.c:#include <sys/syscall.h>
>     toys/other/readahead.c:#include <sys/syscall.h>
>     toys/other/rmmod.c:#include <sys/syscall.h>
>     toys/other/taskset.c:#include <sys/syscall.h>
>     toys/pending/modprobe.c:#include <sys/syscall.h>
>     toys/pending/strace.c:#include <sys/syscall.h>
>     toys/pending/uclampset.c:#include <sys/syscall.h>
> 
>     Is there a reason we haven't got sys/syscall.h in toys.h? Sure, it's not in
>     posix but it apparently originated in BSD:
> 
>     https://www.freebsd.org/cgi/man.cgi?query=syscall&sektion=2&format=html
>     <https://www.freebsd.org/cgi/man.cgi?query=syscall&sektion=2&format=html>
> 
>     So the header should at least _exist_ there, and including it not break the
>     build?
> 
> yeah, there's a <sys/syscall.h> on macOS too. (iirc it's the glibc <syscall.h>
> synonym that's less portable.)

I should do that as a separate checkin so you can at least pull to right before
that if it breaks stuff...

>     Ah. My devuaan kernel is 4.19+fixes, so this goes boing when I run it. Luckily,
>     I created mkroot... Hmmm... Except when I tried your version (without any of my
>     changes), it still went:
> 
>     Type exit when done.
>     # uclampset
>     uclampset: Need -p PID or CMD [ARG...]
>     # uclampset -p $$
>     sh (48) util_clamp: min: 0 max: 0
>     # uclampset -p $$ -m 42
>     uclampset: sched_setattr for pid 48: Not supported
>     # uclampset -p $$ -M 42
>     uclampset: sched_setattr for pid 48: Not supported
>     # cat /proc/version
>     Linux version 5.16.0-rc3 (landley at driftwood) (x86_64-linux-musl-gcc (GCC) 9.2.01
> 
>     Do I need a kernel config entry or something?
> 
> i think so, yes. i got similar results to you on my laptop, but running on an
> x86-64 [virtual] device everything worked [to the extent that "i got back the
> values i put in, and plausible looking numbers from other stuff"].
> 
> i'm guessing it's these?
> 
> vsoc_x86_64:/# gzip -dc /proc/config.gz | grep UCLAMP
> CONFIG_UCLAMP_TASK=y

They added a config symbol for a new feature of an existing syscall.

Why?

> CONFIG_UCLAMP_BUCKETS_COUNT=20
> CONFIG_UCLAMP_TASK_GROUP=y

I think to test this I should just need the first one... Nope:

  Depends on: CPU_FREQ_GOV_SCHEDUTIL [=n]

And THAT needs:

  Depends on: CPU_FREQ [=n] && SMP [=n]

So this feature literally cannot be enabled on a non-SMP kernel. Bravo.

Sigh:

LINUX=~/linux/clean CROSS=x86_64 scripts/mkroot.sh PENDING=uclampset
  KEXTRA=SMP,CPU_FREQ,CPU_FREQ_GOV_SCHEDUTIL,UCLAMP_TASK

And run it on my UP kvm instance because the kernel devs are insane:

# uclampset -p $$
sh (54) util_clamp: min: 0 max: 1024
# uclampset -p $$ -M 1000
# uclampset -p $$
sh (54) util_clamp: min: 0 max: 1000
# uclampset -p $$ -M 0
# uclampset -p $$
sh (54) util_clamp: min: 0 max: 0
# uclampset -p $$ -m 42
uclampset: sched_setattr for pid 54: Invalid argument
# uclampset -p $$ -m 100 -M 600
# uclampset -p $$
sh (54) util_clamp: min: 100 max: 600

What does setting the maximum to zero do? I should check that enabling cgroup
support allows me to set -m above -M (I.E. confirm that their check function is
broken), but can't be bothered.

I guess this feature only enforces the maximum when the system isn't otherwise
idle? -M 0 on the current shell did _not_ hang, so it's either using more than
quota, or rounding its usage accounting down.

(The OpenVZ guys wanted hard accounting for some stuff so people who buy a slice
of an idle server don't complain to support when the rest of the server fills
up. This, I couldn't tell you what it's really doing...)

Rob