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 kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
