On Thu, Jul 23, 2015 at 01:58:20PM -0700, David Rientjes wrote: > On Thu, 23 Jul 2015, Joonsoo Kim wrote: > > > > The slub allocator does try to allocate its high-order memory with > > > __GFP_WAIT before falling back to lower orders if possible. I would think > > > that this would be the greatest sign of on-demand memory compaction being > > > a problem, especially since CONFIG_SLUB is the default, but I haven't seen > > > such reports. > > > > In fact, some of our product had trouble with slub's high order > > allocation 5 months ago. At that time, compaction didn't make high order > > page and compaction attempts are frequently deferred. It also causes many > > reclaim to make high order page so I suggested masking out __GFP_WAIT > > and adding __GFP_NO_KSWAPD when trying slub's high order allocation to > > reduce reclaim/compaction overhead. Although using high order page in slub > > has some gains that reducing internal fragmentation and reducing management > > overhead, benefit is marginal compared to the cost at making high order > > page. This solution improves system response time for our case. I planned > > to submit the patch but it is delayed due to my laziness. :) > > > > Hi Joonsoo, Hello David. > > On a fragmented machine I can certainly understand that the overhead > involved in allocating the high-order page outweighs the benefit later and > it's better to fallback more quickly to page orders if the cache allows > it. > > I believe that this would be improved by the suggestion of doing > background synchronous compaction. So regardless of whether __GFP_WAIT is > set, if the allocation fails then we can kick off background compaction > that will hopefully defragment memory for future callers. That should > make high-order atomic allocations more successful as well. Yep! I also think __GFP_NO_KSWAPD isn't appropriate for general case. Reason I suggested __GFP_NO_KSWAPD to our system is that reclaim/compaction continually fails to make high order page so we don't want to invoke reclaim/compaction even though it works in background. But, on almost of other system, reclaim/compaction could succeed so adding __GFP_NO_KSWAPD doens't make sense for general case. Thanks. -- 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>