From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [Bug #14467] Linker errors on ia64 with NR_CPUS=4096 Date: Thu, 29 Oct 2009 16:11:12 +0100 Message-ID: <4AE9B090.9090107@kernel.org> References: <6dRYo8ss7vL.A.nnF.Cre5KB@chimera> <4AE9AB23.8010207@kernel.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: kernel-testers-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Christoph Lameter Cc: Jiri Kosina , "Rafael J. Wysocki" , Linux Kernel Mailing List , Kernel Testers List , Ingo Molnar , Jeff Mahoney , "Luck, Tony" , Peter Zijlstra , Peter Zijlstra Christoph Lameter wrote: > On Thu, 29 Oct 2009, Tejun Heo wrote: > >> It's just for sched_init() which has irq off but is not really in >> atomic context and does GFP_KERNEL allocations. The following comment >> has been added to the first patch to explain it. > > Uhmm.. Is the page allocator available at that point? If you are > constricted to the reserved per cpu area then IA64 can still run out of > space if its booted with 4096 actual cpus. sched_init() is after mm_init() so it should work. >> + * allocations are done using GFP_KERNEL with pcpu_lock released. In >> + * general, percpu memory can't be allocated with irq off but >> + * irqsave/restore are still used in alloc path so that it can be used >> + * from early init path - sched_init() specifically. > > Maybe make the patch a bit more general so that it can operate in an > atomic context and handles gfp flags nicely? That would be nice but currently, we have no user which needs anything other than GFP_KERNEL although lack of users could have been caused by the lack of the functionality and the non-atomic irq disabled state is an exception case which is handled differently by might_sleep() too. So, I'm not sure whether adding GFP_* parameter would worth the effort. Also, adding that is a bit too late for 2.6.32 at this point. Thanks. -- tejun