Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755202AbZJ2PKz (ORCPT ); Thu, 29 Oct 2009 11:10:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755172AbZJ2PKy (ORCPT ); Thu, 29 Oct 2009 11:10:54 -0400 Received: from hera.kernel.org ([140.211.167.34]:40217 "EHLO hera.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755160AbZJ2PKy (ORCPT ); Thu, 29 Oct 2009 11:10:54 -0400 Message-ID: <4AE9B090.9090107@kernel.org> Date: Thu, 29 Oct 2009 16:11:12 +0100 From: Tejun Heo User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 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 Subject: Re: [Bug #14467] Linker errors on ia64 with NR_CPUS=4096 References: <6dRYo8ss7vL.A.nnF.Cre5KB@chimera> <4AE9AB23.8010207@kernel.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1581 Lines: 37 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 -- 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/