On Sat, Dec 11, 2021 at 11:21 AM Rob Landley <r...@landley.net> wrote:
> On 12/10/21 1:53 PM, enh wrote: > > On Fri, Dec 10, 2021 at 6:52 AM Rob Landley <r...@landley.net > > <mailto:r...@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@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 >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
