Thread (11 messages) 11 messages, 4 authors, 2011-10-12

Re: [PATCH 2/2] mm: Abort reclaim/compaction if compaction can proceed

From: Mel Gorman <mgorman@suse.de>
Date: 2011-10-07 20:24:23
Also in: lkml

On Fri, Oct 07, 2011 at 04:07:06PM -0400, Rik van Riel wrote:
On 10/07/2011 11:17 AM, Mel Gorman wrote:
quoted
If compaction can proceed, shrink_zones() stops doing any work but
the callers still shrink_slab(), raises the priority and potentially
sleeps.  This patch aborts direct reclaim/compaction entirely if
compaction can proceed.

Signed-off-by: Mel Gorman<mgorman@suse.de>
This patch makes sense to me, but I have not tested it like
the first one.
Do if you can.
Mel, have you tested this patch?
Yes.
Did you see any changed
behaviour vs. just the first patch?
It's marginal and could be confirmation bias on my part. Basically,
there is noise when this path is being exercised but there were fewer
slabs scanned.  However, I don't know what the variances are and
whether the reduction was within the noise or not but it makes sense
that it would scan less.  If I profiled carefully, I might be able
to show that a few additional cycles are spent raising the priority
but it would be marginal.

While patch 1 is very clear, patch 2 depends on reviewers deciding it
"makes sense".
Having said that, I'm pretty sure the patch is ok :)
Care to ack?

-- 
Mel Gorman
SUSE Labs

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
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