On 3/5/23 13:01, Rob Landley wrote: > 8-core mac is a new use case. It probably needs to fall back to the old pre-n > behavior (like 80% efficiency on average on my 4x processor laptop I'd guess?) > instead just not using -n when "wait -n" errors (which has side effects).
I reimplemented the old round-robin $PID wait as the fallback when there's no -n. And it's more like 90% efficiency in my testing on my laptop: you can see the tops of the CPU usage bars flutter a bit vs solid in the other one, but it keeps them all mostly busy. (I used to compensate by launching N+1 processes, but didn't put that part back. Not likely to make a measurable difference on >8 processors anyway.) >> this is a lot less noticeable when you have 128 cores, >> because that's "most of defconfig" anyway. but when you only [world's >> tiniest violin] have 10 cores, it's really noticeable [even without >> that patch] the first 10 dots appear instantaneously, but the >> remaining ones appear one-by-one [which is what made me ask ps "what's >> actually going on?"]. there's basically just one compile job running >> at any given time after the first batch on the Mac. it's not _quite_ >> serial though, because on the 128-core box i do see ~4 cc jobs at a >> time after the initial 128 job goldrush. > > And that's a separate issue. I admit I have 4 cores here so wouldn't notice a > limit of more than that, but... what? Did commit dd56ea086435 address this part too, or is there more to do? Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
