Re: [GIT PULL] scheduler fixes

Linus Torvalds
2009-05-18T19:17:19Z

On Mon, 18 May 2009, Ingo Molnar wrote:
>
> Something like the patch below. It also fixes ->span[] which has a
> similar problem.

Patch looks good to me.

> But ... i think this needs further clean-ups really. Either go fully
> static, or go fully dynamic.

I do agree that it would probably be good to try to avoid this static
allocation, and allocate these data structures dynamically. However, if we
end up having to use two different allocators anyway (one for bootup, and
one for regular uptimes), then I think that would be an overall loss
(compared to just the simplicity of statically doing this in a couple of
places), rather than an overall win.

> Would be nice if bootmem_alloc() was extended with such properties -
> if SLAB is up (and bootmem is down) it would return
> kmalloc(GFP_KERNEL) memory buffers.

I would rather say the other way around: no "bootmem_alloc()" at all, but
just have a regular alloc() that ends up working like the "SMP
alternatives" code, but instead of being about SMP, it would be about how
early in the boot sequence it is.

That said, if there are just a couple of places like this that care, I
don't think it's worth it. The static allocation isn't that horrible. I'd
rather have a few ugly static allocations with comments about _why_ they
look the way they do, than try to over-design things to look "clean".

Simplicity is a good thing - even if it can then end up meaning special
cases like this.

That said, if we could move the kmalloc initialization up some more (and
get at least the "boot node" data structures set up, and avoid any bootmem
alloc issues _entirely_, then that would be good.

I hate that stupid bootmem allocator. I suspect we seriously over-use it,
and that we _should_ be able to do the SL*B init earlier.

Linus