<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Dec 11, 2021 at 11:21 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 12/10/21 1:53 PM, enh wrote:<br>
> On Fri, Dec 10, 2021 at 6:52 AM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a><br>
> <mailto:<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>>> wrote:<br>
> <br>
> On 12/9/21 7:31 PM, enh via Toybox wrote:<br>
> > No standard, but part of util-linux.<br>
> <br>
> Don't default y in pending.<br>
> <br>
> yeah, sorry. i realized that after i'd gone to bed. at least i'm consistent ...<br>
> i *always* make that mistake.<br>
<br>
Eh, should be a fairly fast promotion, I just need to get it to _work_ first. :)<br>
<br>
> USE_TASKSET(NEWTOY(uclampset)) doesn't match.<br>
> <br>
> d'oh. _that's_ a new mistake though!<br>
<br>
I usually do it with "USE_HELLO" so have learned to check. :)<br>
<br>
> Does this require root?<br>
> <br>
> as you can tell from the previous mistake, i took taskset as a basis for this.<br>
> it seemed plausible to me that if taskset needed STAYROOT (which i assume is<br>
> what you're asking about here), this would too? but i've no idea.<br>
<br>
I suspect taskset doesn't either. It needs it to set the mask of processes you<br>
don't own, but you should legitimately be root for that?<br></blockquote><div><br></div><div>(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 :-) )</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
(P.S. The kernel says "Invalid argument" for an attempt to set taskset to 0.<br>
That's one of the things I need to be sure to check about this new plumbing...)<br>
<br>
> >From a UI perspective, do we ever _not_ want -a?<br>
> <br>
> i wondered that too, but this is what the util-linux one does. (which is<br>
> presumably just because that's what taskset does. so -- like me with `default y`<br>
> at least they're _consistent_.)<br>
<br>
Complicates the code, but simplifies the help text. Hmmm...<br>
<br>
I suppose I could move -a to the end? There's tension between "options in<br>
alphabetical order so you can find them" and "options in some sort of coherent<br>
order where they make SENSE".<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
You'll note that find.c errs ENTIRELY towards the second, but you've pretty much<br>
GOTTA collate name/iname path/ipath user/nouser group/nogroup, true/false,<br>
depth/maxdepth/mindepth... Plus you'll notice it's totally cheating by having<br>
the "-option explanation" indentation be WAY different on the left (16 chars<br>
after the dash) side than on the right side (11 chars). I kind of want to<br>
collate prune/xdev/empty/quit, but... hmmm, maybe options with no arguments on<br>
the right and ones with arguments on the left? Except I haven't got an equal<br>
number of types. (Plus those last two lines just go all the way across because<br>
there's too much to explain, and newerXY would be right under -newer...)<br>
<br>
Anyway, this kinda polishing thing can eat All The Time if I let it. :)<br>
<br>
> Sigh. It's HARD to come up with a good terse description of -R.<br>
> <br>
> yeah, as you can see, i gave up: "you're going to want to read a man page ---<br>
> here's what you should search for" was all i was going for there.<br>
<br>
-R Reset child processes to default values on fork<br>
<br>
> $ grep syscall\.h toys/*/*.c<br>
> toys/other/chrt.c:#include <sys/syscall.h><br>
> toys/other/insmod.c:#include <sys/syscall.h><br>
> toys/other/ionice.c:#include <sys/syscall.h><br>
> toys/other/nsenter.c:#include <sys/syscall.h><br>
> toys/other/pivot_root.c:#include <sys/syscall.h><br>
> toys/other/readahead.c:#include <sys/syscall.h><br>
> toys/other/rmmod.c:#include <sys/syscall.h><br>
> toys/other/taskset.c:#include <sys/syscall.h><br>
> toys/pending/modprobe.c:#include <sys/syscall.h><br>
> toys/pending/strace.c:#include <sys/syscall.h><br>
> toys/pending/uclampset.c:#include <sys/syscall.h><br>
> <br>
> Is there a reason we haven't got sys/syscall.h in toys.h? Sure, it's not in<br>
> posix but it apparently originated in BSD:<br>
> <br>
> <a href="https://www.freebsd.org/cgi/man.cgi?query=syscall&sektion=2&format=html" rel="noreferrer" target="_blank">https://www.freebsd.org/cgi/man.cgi?query=syscall&sektion=2&format=html</a><br>
> <<a href="https://www.freebsd.org/cgi/man.cgi?query=syscall&sektion=2&format=html" rel="noreferrer" target="_blank">https://www.freebsd.org/cgi/man.cgi?query=syscall&sektion=2&format=html</a>><br>
> <br>
> So the header should at least _exist_ there, and including it not break the<br>
> build?<br>
> <br>
> yeah, there's a <sys/syscall.h> on macOS too. (iirc it's the glibc <syscall.h><br>
> synonym that's less portable.)<br>
<br>
I should do that as a separate checkin so you can at least pull to right before<br>
that if it breaks stuff...<br></blockquote><div><br></div><div>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 :-)</div><div><br></div><div>anyway, github will show you whether you've broken the mac build thanks to emolitor's work.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Ah. My devuaan kernel is 4.19+fixes, so this goes boing when I run it. Luckily,<br>
> I created mkroot... Hmmm... Except when I tried your version (without any of my<br>
> changes), it still went:<br>
> <br>
> Type exit when done.<br>
> # uclampset<br>
> uclampset: Need -p PID or CMD [ARG...]<br>
> # uclampset -p $$<br>
> sh (48) util_clamp: min: 0 max: 0<br>
> # uclampset -p $$ -m 42<br>
> uclampset: sched_setattr for pid 48: Not supported<br>
> # uclampset -p $$ -M 42<br>
> uclampset: sched_setattr for pid 48: Not supported<br>
> # cat /proc/version<br>
> Linux version 5.16.0-rc3 (landley@driftwood) (x86_64-linux-musl-gcc (GCC) 9.2.01<br>
> <br>
> Do I need a kernel config entry or something?<br>
> <br>
> i think so, yes. i got similar results to you on my laptop, but running on an<br>
> x86-64 [virtual] device everything worked [to the extent that "i got back the<br>
> values i put in, and plausible looking numbers from other stuff"].<br>
> <br>
> i'm guessing it's these?<br>
> <br>
> vsoc_x86_64:/# gzip -dc /proc/config.gz | grep UCLAMP<br>
> CONFIG_UCLAMP_TASK=y<br>
<br>
They added a config symbol for a new feature of an existing syscall.<br>
<br>
Why?<br>
<br>
> CONFIG_UCLAMP_BUCKETS_COUNT=20<br>
> CONFIG_UCLAMP_TASK_GROUP=y<br>
<br>
I think to test this I should just need the first one... Nope:<br>
<br>
Depends on: CPU_FREQ_GOV_SCHEDUTIL [=n]<br>
<br>
And THAT needs:<br>
<br>
Depends on: CPU_FREQ [=n] && SMP [=n]<br>
<br>
So this feature literally cannot be enabled on a non-SMP kernel. Bravo.<br>
<br>
Sigh:<br>
<br>
LINUX=~/linux/clean CROSS=x86_64 scripts/mkroot.sh PENDING=uclampset<br>
KEXTRA=SMP,CPU_FREQ,CPU_FREQ_GOV_SCHEDUTIL,UCLAMP_TASK<br>
<br>
And run it on my UP kvm instance because the kernel devs are insane:<br>
<br>
# uclampset -p $$<br>
sh (54) util_clamp: min: 0 max: 1024<br>
# uclampset -p $$ -M 1000<br>
# uclampset -p $$<br>
sh (54) util_clamp: min: 0 max: 1000<br>
# uclampset -p $$ -M 0<br>
# uclampset -p $$<br>
sh (54) util_clamp: min: 0 max: 0<br>
# uclampset -p $$ -m 42<br>
uclampset: sched_setattr for pid 54: Invalid argument<br>
# uclampset -p $$ -m 100 -M 600<br>
# uclampset -p $$<br>
sh (54) util_clamp: min: 100 max: 600<br>
<br>
What does setting the maximum to zero do? I should check that enabling cgroup<br>
support allows me to set -m above -M (I.E. confirm that their check function is<br>
broken), but can't be bothered.<br>
<br>
I guess this feature only enforces the maximum when the system isn't otherwise<br>
idle? -M 0 on the current shell did _not_ hang, so it's either using more than<br>
quota, or rounding its usage accounting down.<br>
<br>
(The OpenVZ guys wanted hard accounting for some stuff so people who buy a slice<br>
of an idle server don't complain to support when the rest of the server fills<br>
up. This, I couldn't tell you what it's really doing...)<br>
<br>
Rob<br>
</blockquote></div></div>