Messages in this thread | | | Date | Thu, 23 Jul 2015 13:58:20 -0700 (PDT) | From | David Rientjes <> | Subject | Re: [RFC 1/4] mm, compaction: introduce kcompactd |
| |
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,
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.
| |