Messages in this thread | | | Date | Fri, 27 Jan 2006 00:29:47 -0800 | From | Sridhar Samudrala <> | Subject | Re: [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/
| |