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

[enh]

On Sat, Dec 11, 2021 at 11:21 AM Rob Landley <rob at landley.net> wrote:

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

(sounds plausible to me, but suid isn't a thing on Android anyway, so (a)
it doesn't matter to me, but (b) it also means you shouldn't trust my
intuition on such things :-) )


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

yeah, when there's a small enough number that you can grok them in a
glance, alphabetical order is definitely best, but even i agree that the
"theme" grouping is necessary for stuff like find.


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

i'm not _actually_ obliged to follow google's wider "no changes close to
holidays" rules, but i don't think i'll be touching anything but
documentation for the rest of 2021 :-)

anyway, github will show you whether you've broken the mac build thanks to
emolitor's work.


> >     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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20211215/67ff8849/attachment.htm>