![]() | ||||||||||
Messages in this thread |
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 | ||||||||||