lkml.org 
[lkml]   [2006]   [Jan]   [27]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
    /
    DateFri, 27 Jan 2006 00:29:47 -0800
    FromSridhar Samudrala <>
    SubjectRe: [patch 0/9] Critical Mempools
    Matthew Dobson wrote:
    > Christoph Lameter wrote:> >> On Thu, 26 Jan 2006, Matthew Dobson wrote:>>>>>> >>>> All subsystems will now get more complicated by having to add this 
    >>>> emergency functionality?>>>> >>> Certainly not.  Only subsystems that want to use emergency pools will get
    >>> more complicated.  If you have a suggestion as to how to implement a
    >>> similar feature that is completely transparent to its users, I would *love*
    >>> >> I thought the earlier __GFP_CRITICAL was a good idea.
    >> >> Well, I certainly could have used that feedback a month ago! ;)  The
    > general response to that patchset was overwhelmingly negative.  Yours is
    > the first vote in favor of that approach, that I'm aware of.
    >>> >>> to hear it.  I have tried to keep the changes to implement this
    >>> functionality to a minimum.  As the patches currently stand, existing slab
    >>> allocator and mempool users can continue using these subsystems without
    >>> modification.>>> >> The patches are extensive and the required changes to subsystems in order 
    >> to use these pools are also extensive.>> >> I can't really argue with your first point, but the changes required to use
    > the pools should actually be quite small.  Sridhar (cc'd on this thread) is
    > working on the changes required for the networking subsystem to use these
    > pools, and it looks like the patches will be no larger than the ones from
    > the last attempt.> 
    I would say that the patches to support critical sockets will be 
    slightly more complex with mempools
    than the earlier patches that used the global critical page pool with a 
    new GFP_CRITICAL flag.
    
    Basically we need a facility to mark an allocation request as critical 
    and satisfy this request without
    any blocking in an emergency situation.
    
    Thanks
    Sridhar
    >> >>>> There surely must be a better way than revising all subsystems for 
    >>>> critical allocations.>>>> >>> Again, I could not find any way to implement this functionality without
    >>> forcing the users of the functionality to make some, albeit very minor,
    >>> changes.  Specific suggestions are more than welcome! :)
    >>> >> Gfp flag? Better memory reclaim functionality?>> >> Well, I've got patches that implement the GFP flag approach, but as I
    > mentioned above, that was poorly received.  Better memory reclaim is a
    > broad and general approach that I agree is useful, but will not necessarily
    > solve the same set of problems (though it would likely lessen the severity
    > somewhat).>> -Matt> 
    
    
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    
    
    \
     
     \ /
      Last update: 2006-01-27 09:32    [from the cache]
    ©2003-2008