Messages in this thread | | | Date | Sat, 3 Jan 2009 12:56:03 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [git pull] cpus4096 tree, part 3 |
| |
On Sat, 3 Jan 2009, Ingo Molnar wrote: > > > Has anybody looked at what the stack size is with MAXSMP set with an > > allyesconfig? And what areas are still problematic, if any? Are we going > > to have some code-paths that still essentially have 1kB+ of stack space > > just because they haven't been converted and still have the cpu mask on > > stack? > > ok, indeed testing of that is in order now.
Well, since I can compile a allyesconfig pretty quickly, I did the static part. It looks better than it used to, and I think most of the huge stacks are totally unrealted to cpu masks. But not all.
But it looks like we have a few:
- flush_tlb_current_task: cpumask_t cpu_mask; - flush_tlb_mm: cpumask_t cpu_mask; - local_cpus_show: cpumask_t mask; - local_cpulist_show: cpumask_t mask; - acpi_cpufreq_target: cpumask_t online_policy_cpus
and then we have a number of things that have "struct cpufreq_policy" on the stack, and those things have two cpumask_t's in each.
The rest of the high-stack-usage cases - from a _very_ quick look - seem to be unrelated to CPU masks, but in the "more than 1kB of stack" group about a third (wild handwaving eyeballing) of them do seem to be related to cpumask.
And those things (VM, ACPI and PCI) are easily triggered in real use and don't need odd hardware. So I think they need to be fixed before 2.6.29, otherwise I'll have to disable MAXSMP and again limit MAX_CPU back to 128 or something.
Linus
| |