Re: [patch 0/9] Critical Mempools

[Sridhar Samudrala <sri@us.ibm.com>]

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
>