Re: [patch 0/9] Critical Mempools

[Sridhar Samudrala]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/