Re: [GIT PULL] scheduler fixes

[Nick Piggin]

On Mon, May 25, 2009 at 11:47:40AM +0300, Pekka Enberg wrote:
> On Mon, 25 May 2009, Ingo Molnar wrote:
> > Ok, i think this all looks pretty realistic - but there's quite a 
> > bit of layering on top of pending changes in the x86 and irq trees. 
> > We could do this on top of those topic branches in -tip, and rebase 
> > in the merge window. Or delay it to .32.
> > 
> > ... plus i think we are _very_ close to being able to remove all of 
> > bootmem on x86 (with some compatibility/migration mechanism in 
> > place). Which bootmem calls do we have before kmalloc init with 
> > Pekka's patch applied? I think it's mostly the page table init code.
> >  
> > ( beyond the page allocator internal use - where we could use 
> >   straight e820 based APIs that clip memory off from the beginning 
> >   of existing e820 RAM ranges - enriched with NUMA/SRAT locality 
> >   info. )
> 
> OK, here's a version of the patch with Yinghai's rebasing on top of 
> tip/master. All in-kernel memory allocators boot cleanly now on my 
> configuration (I did not try SLQB but it probably needs fixing). I would 
> appreciate if someone gave SLAB+NUMA configuration a try.
> 
> Ingo, I don't really want to carry this in slab.git so perhaps you could 
> put this and Yinghai's irq init cleanup in a "earlyslab" branch in tip for 
> testing?
> 
> And oh, Christoph/Matt, can I have your NAK/ACK for this patch?
> 
> 			Pekka
> 
> >From f5338db5f1b959cb82ed811037a545e19c7b2b7b Mon Sep 17 00:00:00 2001
> From: Pekka Enberg <penberg@xxxxxxxxxxxxxx>
> Date: Mon, 25 May 2009 09:44:39 +0300
> Subject: [PATCH] slab: setup allocators earlier in the boot sequence
> 
> This patch makes kmalloc() available earlier in the boot sequence so we can get
> rid of some bootmem allocations. The bulk of the changes are due to
> kmem_cache_init() being called with interrupts disabled which requires some
> changes to allocator boostrap code.
> 
> [ yinghai@xxxxxxxxxx: rebase to tip ]
> Cc: Nick Piggin <npiggin@xxxxxxx>
> Cc: Matt Mackall <mpm@xxxxxxxxxxx>
> Cc: Christoph Lameter <cl@xxxxxxxxxxxxxxxxxxxx>
> Cc: Linus Torvalds <torvals@xxxxxxxxxxxxxxxxxxxx>
> Signed-off-by: Pekka Enberg <penberg@xxxxxxxxxxxxxx>
> ---
>  init/main.c           |   28 +++++++++-------
>  kernel/irq/handle.c   |   23 +++++---------
>  kernel/sched.c        |   34 +++++++------------
>  kernel/sched_cpupri.c |    9 +++--
>  mm/slab.c             |   85 ++++++++++++++++++++++++++-----------------------
>  mm/slub.c             |   17 ++++++----
>  6 files changed, 98 insertions(+), 98 deletions(-)
> 
> diff --git a/init/main.c b/init/main.c
> index 33ce929..e7a9c18 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -576,6 +576,22 @@ asmlinkage void __init start_kernel(void)
>  	setup_nr_cpu_ids();
>  	smp_prepare_boot_cpu();	/* arch-specific boot-cpu hooks */
>  
> +	build_all_zonelists();
> +	page_alloc_init();
> +
> +	printk(KERN_NOTICE "Kernel command line: %s\n", boot_command_line);
> +	parse_early_param();
> +	parse_args("Booting kernel", static_command_line, __start___param,
> +		   __stop___param - __start___param,
> +		   &unknown_bootoption);
> +	/*
> +	 * Setup kernel memory allocators
> +	 */
> +	pidhash_init();
> +	vmalloc_init();
> +	vfs_caches_init_early();
> +	mem_init();
> +	kmem_cache_init();

Looks quite OK to me. The comment above maybe misleading?

The bootmem allocations of course are required because some hashes may
need to be larger than MAX_ORDER without using vmalloc.

kmem_cache_init (and mem_init, partially) sets up the kernel memory
allocators...

I can take a look at the SLQB side.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/