On Tue, 17 Jan 2023, Sebastian Andrzej Siewior wrote: > On 2023-01-16 13:58:42 [-0500], John Kacur wrote: > > > > Okay, not sure how that adds to the conversation. I'm all for "sane" > > defaults for --smp too, but we care about other kinds of invocations too. > > As soon as I get a patch that doesn't break other things as well, I'll > > apply it. > > BROKEN IT IS. Well something is broken isn't it? But could it be your BIOS then? This does work for most people on most machines. The thing I'm always on the look out for is making sure a fix for one problem doesn't cause problems elsewhere. > > I want to use that and not fix every time I use it. Using > -S -p 90 -d0 -m > > are already a lot of options just for a simple test to use all CPUs on a > system. This used to work on this machine. Now it starts way more > threads than I have CPUs. I accept that this might be something that > someone wants to test so he can use -t 100. But the simple test that is > no longer working. srsly. Starting more threads than the current > available online CPUs or even CPU affinity makes no sense since the > results with equal priority distribution or not reproducible. Right, your patch said "For default configuration, only with the -S option" So, I looked at the code, and thought, this could be called for OPT_THREADS as well as for OPT_SMP That's the only thing I asked you to address. However, taking a step back, I think it will work fine for OPT_THREADS as well. In fact we used to do it that way, it got changed here. commit 76ad600da83771dc4985b4a9db1f63344bb364cb with what certainely seemed like a sane clean-up. So, I'm just going to do a little more testing, and make sure it doesn't break rteval, and then I'll likely apply your patch. John > > > John > > Sebastian >
