Messages in this thread | | | Date | Mon, 10 Nov 2008 11:47:20 -0800 | From | "Yinghai Lu" <> | Subject | Re: [RFC PATCH] sparse_irq aka dyn_irq |
| |
On Mon, Nov 10, 2008 at 2:09 AM, Ingo Molnar <mingo@elte.hu> wrote: > > * Yinghai Lu <yinghai@kernel.org> wrote: > >> Ingo Molnar wrote: >> > * Yinghai Lu <yinghai@kernel.org> wrote: >> > >> >> Andrew Morton wrote: >> >>> On Mon, 10 Nov 2008 10:40:33 +0100 Ingo Molnar <mingo@elte.hu> wrote: >> >>> >> >>>>>>> @@ -987,6 +988,8 @@ void __init mem_init(void) >> >>>>>>> >> >>>>>>> set_highmem_pages_init(); >> >>>>>>> >> >>>>>>> + after_bootmem = 1; >> >>>>>> this hack can go away once we have a proper percpu_alloc() that can be >> >>>>>> used early enough. >> >>>>> where is that fancy patch? current percpu_alloc(), will keep big >> >>>>> pointer in array..., instead of put that pointer in percpu_area >> >>>>> >> >>>>> 64bit has that after_bootmem already. >> >>>> or at least introduce a "bootmem agnostic" allocator instead of >> >>>> open-coding the after_bootmem flag. >> >>>> >> >>>> Something like: >> >>>> >> >>>> early_kzalloc() >> >>>> >> >>>> ? >> >>>> >> >>>> Andrew, any preferences? >> >>> My mind reading ain't what it was, and this after_bootmem flag is >> >>> write-only in this patch. >> >>> >> >>> So what's all this about? >> >> if i use alloc_bootmem to get some memory, and later after_bootmem, >> >> can I use kfree to free it? >> > >> > hm, no. If we used alloc_bootmem(), then we must not free it after >> > after_bootmem has been set. >> >> ok, let keep irq_desc for legacy irqs not movable... > > most of them are movable right now, correct? If we restrict their > movability now that might surprise existing usecases negatively.
i mean irq_desc will not be allocated one one on new cpus...
YH
| |