On Mon, Jul 20, 2015 at 09:43:02PM +0530, PINTU KUMAR wrote: > Hi, > > Thank you all for reviewing the patch and providing your valuable comments and > suggestions. > During the ELC conference many people suggested to release the patch to > mainline, so this patch, to get others opinion. > Unfortunately, in my opinion it runs the risk of creating a different set of problems. Either it needs to be run frequently to keep memory free which incurs one set of penalties or it is used too late when there are unmovable/unreclaimable pages preventing allocations succeeding in which case you are back at the original problem. I see what you did and why it would work in some cases but I think the main reason it works is because it's run frequently enough so memory is never used. Grouping pages by mobility actually took advantage of a similar property when it increased min_free_kbytes but that was much more limited than adding a giant hammer for userspace to reclaim the world. > If you have any more suggestions to experiment and verify please let me know. > I believe I already did. If it's high-order reliability that is important then you need to either reserve the memory or look at protecting the pages using grouping pages by mobility. I pointed out what series to look at and the leader explains how it could be adjusted further for the embedded case if necessary. If it's latency you are interested in then reclaim/compaction needs to be modified to be more aggressive when it is somehow detected that the high-order allocation must succeed for functional correctness. In that case the relational starting point would be to look at should_continue_reclaim and how it relates to compaction. > The suggestion was only to open up the shrink_all_memory API for some use cases. > > I am not saying that it needs to be called continuously. It can be used only on > certain condition and only when deemed necessary. > The same technique is already used in hibernation to reduce the RAM snapshot > image size. Reducing memory usage is not the same as guaranteeing that high-order pages are available for allocation. -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>