Messages in this thread | | | Subject | Re: 2.6.17-mm6 | From | Steven Rostedt <> | Date | Tue, 11 Jul 2006 23:55:21 -0400 |
| |
On Wed, 2006-07-05 at 17:25 -0700, Andrew Morton wrote: > On Wed, 5 Jul 2006 17:05:49 -0700 > "Keith Mannthey" <kmannth@gmail.com> wrote: > > > On 7/5/06, Andrew Morton <akpm@osdl.org> wrote: > > > On Wed, 5 Jul 2006 16:44:57 -0700 > > > Andrew Morton <akpm@osdl.org> wrote: > > > > > > > I guess a medium-term fix would be to add a boot parameter to override > > > > PERCPU_ENOUGH_ROOM - it's hard to justify increasing it permanently just > > > > for the benefit of the tiny minority of kernels which are hand-built with > > > > lots of drivers in vmlinux. > >
[snip]
> > So you've been hit by the expansion of NR_IRQS which bloats kernel_stat > which gobbles per-cpu data. > > In 2.6.17 NR_IRQS is 244. In -mm (due to the x86_64 genirq conversion) > NR_IRQS became (256 + 32 * NR_CPUS). Hence the kstat "array" became > two-dimensional. It's now O(NR_CPUS^2). > > I don't know what's a sane max for NR_CPUS on x86_64, but that'll sure be a > showstopper if the ia64 guys try the same trick. > > I guess one fix would be to de-percpuify kernel_stat.irqs[]. Or > dynamically allocate it with alloc_percpu().
And people wondered why I'm fighting for the robust per_cpu variables.
http://marc.theaimsgroup.com/?l=linux-kernel&m=114785997413023&w=2
Yes there's still problems with this. But if I ever get some more time to work on it, I would like to solve those issues. Having that PERCPU_ENOUGH_ROOM laying around in the kernel is just disgusting ;)
Sorry, for the noise, I have another 2288 more LKML emails to read :)
-- Steve
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |