lkml.org 
[lkml]   [2006]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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    [W:0.123 / U:0.728 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site