Re: [PATCH] rt-numa: Use a reasonable default max CPU value.

[John Kacur <jkacur@redhat.com>]

On Mon, 16 Jan 2023, Ahmed S. Darwish wrote:

> On Mon, 16 Jan 2023, John Kacur wrote:
> >
> > On Thu, 12 Jan 2023, Sebastian Andrzej Siewior wrote:
> >
> > > numa_num_task_cpus() returns here > 100 CPUs while the system has only
> > > 32 populated. The BIOS assumes that I can probably use larger CPUs (with
> > > more cores) on the socket so the number of "configured CPUs" is rather
> > > high.
> > > For default configuration, only with the -S option, it makes sense to
> > > use the current affinity instead looking at the number of possible CPUs
> > > which could be brought online. It still depends on the affinity of the
> > > created threads if the additional CPUs can be used. In a container setup
> > > this may not be the case.
> > >
> > > Use sched_getaffinity() to figure out the number of possible CPUs.
> ...
> >
> > In cyclictest we have
> >
> > 	if (num_threads == -1)
> > 		num_threads = get_available_cpus(affinity_mask);
> >
> >
> > But the num_threads can be set to -1 in OPT_THREADS too,
> > not just for OPT_SMP
> 
> A sane default for --smp, which is almost-always used in sane cyclictest
> invocations, is still valuable IMHO.
> 
> Thanks,
> 
> --
> Ahmed S. Darwish
> Linutronix GmbH
> 

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.

John