* Nathan Zimmer <nzimmer@xxxxxxx> wrote: > The memory we set aside in the previous patch needs to be reinserted. > We start this process via late_initcall so we will have multiple cpus to do > the work. > > Signed-off-by: Mike Travis <travis@xxxxxxx> > Signed-off-by: Nathan Zimmer <nzimmer@xxxxxxx> > Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > Cc: Ingo Molnar <mingo@xxxxxxxxxx> > Cc: "H. Peter Anvin" <hpa@xxxxxxxxx> > Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > Cc: Yinghai Lu <yinghai@xxxxxxxxxx> > --- > arch/x86/kernel/e820.c | 129 +++++++++++++++++++++++++++++++++++++++++++++++++ > drivers/base/memory.c | 83 +++++++++++++++++++++++++++++++ > include/linux/memory.h | 5 ++ > 3 files changed, 217 insertions(+) > > diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c > index 3752dc5..d31039d 100644 > --- a/arch/x86/kernel/e820.c > +++ b/arch/x86/kernel/e820.c > @@ -23,6 +23,7 @@ > > #ifdef CONFIG_DELAY_MEM_INIT > #include <linux/memory.h> > +#include <linux/delay.h> > #endif > > #include <asm/e820.h> > @@ -397,6 +398,22 @@ static u64 min_region_size; /* min size of region to slice from */ > static u64 pre_region_size; /* multiply bsize for node low memory */ > static u64 post_region_size; /* multiply bsize for node high memory */ > > +static unsigned long add_absent_work_start_time; > +static unsigned long add_absent_work_stop_time; > +static unsigned int add_absent_job_count; > +static atomic_t add_absent_work_count; > + > +struct absent_work { > + struct work_struct work; > + struct absent_work *next; > + atomic_t busy; > + int cpu; > + int node; > + int index; > +}; > +static DEFINE_PER_CPU(struct absent_work, absent_work); > +static struct absent_work *first_absent_work; That's 4.5 GB/sec initialization speed - that feels a bit slow and the boot time effect should be felt on smaller 'a couple of gigabytes' desktop boxes as well. Do we know exactly where the 2 hours of boot time on a 32 TB system is spent? While you cannot profile the boot process (yet), you could try your delayed patch and run a "perf record -g" call-graph profiling of the late-time initialization routines. What does 'perf report' show? Delayed initialization makes sense I guess because 32 TB is a lot of memory - I'm just wondering whether there's some low hanging fruits left in the mem init code, that code is certainly not optimized for performance. Plus with a struct page size of around 64 bytes (?) 32 TB of RAM has 512 GB of struct page arrays alone. Initializing those will take quite some time as well - and I suspect they are allocated via zeroing them first. If that memset() exists then getting rid of it might be a good move as well. 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. ] 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