Ingo Molnar wrote: > * Christoph Lameter <cl@xxxxxxxxxxxxxxxxxxxx> wrote: > >> Alan D. Brunelle wrote: >> >>> I think you're right: the kernel as a whole may not be ready for 4,096 >>> CPUs apparently... >> Mike has been working diligently on getting all these cpumasks off the >> stack for the last months and has created an infrastructure to do >> this. So I think we are close. It might just be a matter of merging >> some more patches that are still left in Ingo's tree. > > hm, there are no such patches left that i know of - the only bits in > -tip are the zero-based percpu, which was found to be a bit fragile in > testing: Yes, it's just a case of new changes abusing the stack. > > earth4:~/tip> git-log-line --author=Travis linus.. > d379497: Zero based percpu: infrastructure to rebase the per cpu area to zero > b3a0cb4: x86: extend percpu ops to 64 bit > > [and it has no relevance to stack footprint.] > > So i dont think the current cpumask_t approach will work. We simply > should not get into an endless fight against the windmills that > introduce on-stack cpumask_t again and again. We should just take the > plunge once and do a clean alloc/free cpumask model. Most of the hotpath > cpumasks are constant or pre-constructed, so they are not a real issue. It would have been nice to know this 9 months ago... ;-) > > Plus, on the general question of stack footprint problems and the > difficulty of debugging them, the worst-case stack footprint tracer i > wrote for -rt some time ago should be dusted off as well and put into > ftrace. David has something quite close to that for Sparc64 already. > > Ingo I'll start experimenting with globally changing cpumask_t to be a pointer, and see what falls out. Thanks, Mike -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
