lkml.org 
[lkml]   [2016]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] mm, vmscan: Give up balancing node for high order allocations earlier
On Tue, Jul 12, 2016 at 02:32:45PM +0800, Hillf Danton wrote:
> > > To avoid excessive reclaim, we give up rebalancing for high order
> > > allocations right after reclaiming enough pages.
> >
> > hm. What are the observed runtime effects of this change? Any testing
> > results?
> >
> This work was based on Mel's work, Sir,
> "[PATCH 00/27] Move LRU page reclaim from zones to nodes v7".
>

I believe Andrew understands that but the question is what is the
observed runtime effect of the patch?

> In "[PATCH 06/27] mm, vmscan: Make kswapd reclaim in terms of nodes",
> fragmentation detection is introduced to avoid excessive reclaim. We bail
> out of balancing for high-order allocations if the pages reclaimed at the
> __current__ reclaim priority are two times more than required.
>
> In this work we give up reclaiming for high-order allocations if the
> __total__ number of pages reclaimed, from the first priority to the
> current priority, is more than needed, and in net result we reclaim less
> pages.
>

While it's clear what it does, it is not clear if it is an improvement. I had
read the patch, considered merging it and decided against it. This decision
was based on the fact the series did not appear to be over-reclaiming for
high-order pages when compared with zone-lru.

Did you test this patch with a workload that requires a lot of high-order
pages and see if kswapd was over-reclaiming and that this patch addressed
the issue?

--
Mel Gorman
SUSE Labs

\
 
 \ /
  Last update: 2016-07-12 10:41    [W:0.073 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site