lkml.org 
[lkml]   [2009]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT PULL v2] Early SLAB fixes for 2.6.31
    On Tue, Jun 16, 2009 at 11:45:24AM -0700, Linus Torvalds wrote:
    >
    >
    > On Tue, 16 Jun 2009, Nick Piggin wrote:
    >
    > > On Tue, Jun 16, 2009 at 07:31:38AM +1000, Benjamin Herrenschmidt wrote:
    > > > On Mon, 2009-06-15 at 13:23 +0200, Nick Piggin wrote:
    > > > > > I think the main problem isn't necessarily init code per se, but the
    > > > > > pile of -common- code that can be called both at init time and
    > > > > later.
    > > > >
    > > > > Just seems bogus argument. Everwhere else that does this (ie.
    > > > > allocations that are called from multiple allocation contexts)
    > > > > passes correct gfp flags down.
    > > >
    > > > So you say we should create new variants of all these APIs that take gfp
    > > > flags as arguments just because they might be called early during boot :
    > >
    > > No, just create the ones that actually are called in early boot.
    >
    > No.
    >
    > Nick, I don't think you've follow the problems.
    >
    > The thing is, we do end up wanting to do a lot of allocations, and it's
    > not even very "early" - we've already initialized all the allocators. It's
    > just that WE HAVE NOT ENABLED INTERRUPTS YET!

    Right, I know.


    > So the "hack" is to let everybody act as if everything is normal. Which it
    > pretty much is. Just use kmalloc/kfree etc, and use _all_ the regular
    > functions. Setting up the core layers so that we _can_ enable interrupts
    > involves quite a lot of random crud, they should be able to use regular
    > code.

    I just don't quite see why the problem got bigger though. Doing
    earlier slab allocations than we had previously is going to be
    replacing even more specialised code using bootmem right? I know
    there are a few hacks for this, but I don't see anywhere getting
    *worse* and I don't see anywhere that is all that bad today.


    > And the hack is there because we really are in a magic stage. The memory
    > management works, but it just can't do certain things yet. It's not the
    > callers that need to be changed, because the callers are usually regular
    > routines that work perfectly normally long after boot, and having to add a
    > magic "I'm now doign this during early boot" argument to the whole stack
    > is just _stupid_, when the stack itself doesn't actually care - only the
    > allocators do.

    In some cases perhaps it is difficult. In others it should be
    pretty natural. Lots of memory allocating paths pass gfp
    a long way down the stack.



    \
     
     \ /
      Last update: 2009-06-17 09:49    [W:4.730 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site