On 2016/9/13 21:28, Michal Hocko wrote: > On Tue 13-09-16 21:13:21, zhong jiang wrote: >> On 2016/9/13 1:44, Michal Hocko wrote: > [...] >>> If you want to solve this problem properly then you would have to give >>> tasks which are looping in the page allocator access to some portion of >>> memory reserves. This is quite tricky to do right, though. >> To use some portion of memory reserves is almost no effect in a so >> starvation scenario. I think the hungtask still will occur. it can >> not solve the problem primarily. > Granting an access to memory reserves is of course no full solution but > it raises chances for a forward progress. Other solutions would have to > guarantee that the memory reclaimed on behalf of the requester will be > given to the requester. Not an easy task > >>> Retry counters with the fail path have been proposed in the past and not >>> accepted. >> The above patch have been tested by runing the trinity. The question >> is fixed. Is there any reasonable reason oppose to the patch ? or it >> will bring in any side-effect. > Sure there is. Low order allocations have been traditionally non failing > and changing that behavior is a major obstacle because it opens up a > door to many bugs. I've tried to do something similar in the past and > there was a strong resistance against it. Believe me been there done > that... > That sounds resonable. but So starvation scenario should unavoidable failed. In any case you mean we need allow to allocate the low order. -- 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>