lkml.org 
[lkml]   [2015]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC 1/4] mm, compaction: introduce kcompactd
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.


\
 
 \ /
  Last update: 2015-07-24 07:41    [W:0.125 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site