Messages in this thread | | | Date | Tue, 19 Nov 2013 20:09:04 +0100 | From | Ingo Molnar <> | Subject | Re: [GIT PULL] core kernel update |
| |
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, Nov 19, 2013 at 7:42 AM, Ingo Molnar <mingo@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?
| |