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