Thread (8 messages) 8 messages, 3 authors, 2016-07-18

Re: [patch] mm, compaction: make sure freeing scanner isn't persistently expensive

From: David Rientjes <rientjes@google.com>
Date: 2016-07-11 23:02:01
Also in: lkml

On Thu, 30 Jun 2016, Joonsoo Kim wrote:
We need to find a root cause of this problem, first.

I guess that this problem would happen when isolate_freepages_block()
early stop due to watermark check (if your patch is applied to your
kernel). If scanner meets, cached pfn will be reset and your patch
doesn't have any effect. So, I guess that scanner doesn't meet.
If the scanners meet, we should rely on deferred compaction to suppress 
further attempts in the near future.  This is outside the scope of this 
fix.
We enter the compaction with enough free memory so stop in
isolate_freepages_block() should be unlikely event but your number
shows that it happens frequently?
It's not the only reason why freepages will be returned to the buddy 
allocator: if locks become contended because we are spending too much time 
compacting memory, we can persistently get free pages returned to the end 
of the zone and then repeatedly iterate >100GB of memory on every call to 
isolate_freepages(), which makes its own contended checks fire more often.  
This patch is only an attempt to prevent lenghty iterations when we have 
recently scanned the memory and found freepages to not be isolatable.
In addition, I worry that your previous patch that makes
isolate_freepages_block() stop when watermark doesn't meet would cause
compaction non-progress. Amount of free memory can be flutuated so
watermark fail would be temporaral. We need to break compaction in
this case? It would decrease compaction success rate if there is a
memory hogger in parallel. Any idea?
In my opinion, which I think is quite well known by now, the compaction 
freeing scanner shouldn't be checking _any_ watermark.  The end result is 
that we're migrating memory, not allocating additional memory; determining 
if compaction should be done is best left lower on the stack.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help