Messages in this thread | | | Date | Fri, 27 Jan 2006 00:34:26 -0800 | From | Sridhar Samudrala <> | Subject | Re: [patch 0/9] Critical Mempools |
| |
Benjamin LaHaise wrote: > On Thu, Jan 26, 2006 at 03:32:14PM -0800, Matthew Dobson wrote: > >>> 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. >> > > Personally, I'm more in favour of a proper reservation system. mempools > are pretty inefficient. Reservations have useful properties, too -- one > could reserve memory for a critical process to use, but allow the system > to use that memory for easy to reclaim caches or to help with memory > defragmentation (more free pages really helps the buddy allocator). > > >>> 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). >> > > Which areas are the priorities for getting this functionality into? > Networking over particular sockets? A GFP_ flag would plug into the current > network stack trivially, as sockets already have a field to store the memory > allocation flags. > Yes, i have posted patches that use this exact approach last month that use a critical page pool with GFP_CRITICAL flag. http://lkml.org/lkml/2005/12/14/65 http://lkml.org/lkml/2005/12/14/66
Thanks Sridhar
- 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/
| |