From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Travis Subject: Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected Date: Tue, 26 Aug 2008 12:48:58 -0700 Message-ID: <48B45E2A.6090102@sgi.com> References: <48B29F7B.6080405@hp.com> <48B2A421.7080705@hp.com> <48B313E0.1000501@hp.com> <48B32458.5020104@hp.com> <48B32D39.5040709@linux-foundation.org> <20080826075937.GB7596@elte.hu> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20080826075937.GB7596-X9Un+BFzKDI@public.gmane.org> Sender: kernel-testers-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Ingo Molnar Cc: Christoph Lameter , "Alan D. Brunelle" , Linus Torvalds , "Rafael J. Wysocki" , Linux Kernel Mailing List , Kernel Testers List , Andrew Morton , Arjan van de Ven , Rusty Russell , Jack Steiner Ingo Molnar wrote: > * Christoph Lameter 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