* H. Peter Anvin <hpa@xxxxxxxxx> wrote: > On 06/23/2013 02:32 AM, Ingo Molnar wrote: > > > > * Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > > >> Yet another thing to consider would be to implement an initialization > >> speedup of 3 orders of magnitude: initialize on the large page (2MB) > >> grandularity and on-demand delay the initialization of the 4K granular > >> struct pages [but still allocating them] - which I suspect are a good > >> chunk of the overhead? That way we could initialize in 2MB steps and speed > >> up the 2 hours bootup of 32 TB of RAM to 14 seconds... > >> > >> [ The cost would be one more branch in the buddy allocator, to detect > >> not-yet-initialized 2 MB chunks as we encounter them. Acceptable I > >> think. ] > > > > One advantage of this scheme would be that we could use it on pretty much > > any box, it would provide instant boot time speedups everywhere [a couple > > of hundred msecs on a small 4GB box - significant I think] - and would > > spread out and parallelize initialization to later stages. > > Even better if we could start at the 1 GB level, which most of these > really huge machines will have hardware support for. That might be a bit too granular: if we hit such an uninitialized block of memory we'd have to process 262,144 pages - potentially from an IRQ handler that does GFP_ATOMIC... or other latency critical code. With 2MB we'd have to on-demand initialize 512 pages, which shouldn't show up during normal use. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
