* Linus Torvalds <torva...@linux-foundation.org> wrote:
> On Tue, Nov 19, 2013 at 7:42 AM, Ingo Molnar <mi...@kernel.org> wrote:
> >
> > Josh Boyer (1):
> > smp/cpumask: Make CONFIG_CPUMASK_OFFSTACK=y usable without debug
> > dependency
>
> This seems to be just pure stupid.
>
> Why the hell should we ever ask the user whethr they want to force
> CPUMASK offstack?
>
> Seriously, it only leaves room for mistakes and stupidities. There
> is no reason for any normal use-case to ask the user about this.
> Even the help message is pure and utter garbage ("This is a bit more
> expensive, but avoids stack overflow").
>
> The fact is, an on-stack CPUMASK is *smaller* than a pointer to an
> offstack one when NR_CPU is small. The question makes no sense then.
> And when NR_CPU is huge, the question makes no sense _either_, since
> we can't have the cpumasks on stack.
You are completely right. I missed that, will fix it up.
So we have these CPU count ranges right now:
config NR_CPUS
int "Maximum number of CPUs" if SMP && !MAXSMP
range 2 8 if SMP && X86_32 && !X86_BIGSMP
range 2 512 if SMP && !MAXSMP && !CPUMASK_OFFSTACK
range 2 8192 if SMP && !MAXSMP && CPUMASK_OFFSTACK && X86_64
As you pointed out offstack is definitely nonsensical for
NR_CPUS <= 64. (on 64-bit CPUs) On-stack is known to crash with
NR_CPUS >= 1024.
The 128..512 CPUs range is somewhat of an unknown.
So the fixed code would always use on-stack cpumasks up to a limit
(which limit falls into the 128...512 range) and it would always use
off-stack cpumasks above that limit. No user configurability in the
regular case. [*]
The actual value of the limit - here's the on-stack cpumask sizes of
the candidate range:
128 CPUs: 16 byte cpumasks
256 CPUs: 32 byte cpumasks
512 CPUs: 64 byte cpumasks
512 definitely 'feels' dangerous, so I'd say the limit should be
either 128 or 256. Both are ridiculously high counts for regular
systems, so it doesn't really matter which one we pick.
I'd guess we should pick the higher limit for the time being (256 CPUs
- maybe even 512 CPUs), and lower it on contrary evidence (evidence of
stack overflows)?
Thoughts?
Thanks,
Ingo
[*] Plus perhaps allow offstack to be configurable arbitrarily if
debugging is enabled [DEBUG_PER_CPU_MAP=y], to allow easy
experiments/measurements?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
