Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1440944 > unrolled thread

Re: [PATCH] mm, vmscan: Give up balancing node for high order allocations earlier

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] mm, vmscan: Give up balancing node for high order  allocations earlier Andrew Morton <akpm@linux-foundation.org> - 2016-07-12 00:30 +0200
    Re: [PATCH] mm, vmscan: Give up balancing node for high order allocations earlier "Hillf Danton" <hillf.zj@alibaba-inc.com> - 2016-07-12 08:40 +0200
      Re: [PATCH] mm, vmscan: Give up balancing node for high order  allocations earlier Mel Gorman <mgorman@techsingularity.net> - 2016-07-12 10:40 +0200
        Re: [PATCH] mm, vmscan: Give up balancing node for high order allocations earlier "Hillf Danton" <hillf.zj@alibaba-inc.com> - 2016-07-12 10:50 +0200

#1440944 — Re: [PATCH] mm, vmscan: Give up balancing node for high order allocations earlier

On Wed, 29 Jun 2016 13:42:12 +0800 "Hillf Danton" <hillf.zj@alibaba-inc.com> 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?

[toc] | [next] | [standalone]

#1441085 — Re: [PATCH] mm, vmscan: Give up balancing node for high order allocations earlier

> > 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".

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.

Given " [PATCH 00/34] Move LRU page reclaim from zones to nodes v9" 
is delivered, I will send this work if necessary, after Mel's work landing 
in the -mm tree.

thanks
Hillf

[toc] | [prev] | [next] | [standalone]

#1441141

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

[toc] | [prev] | [next] | [standalone]

#1441145 — Re: [PATCH] mm, vmscan: Give up balancing node for high order allocations earlier

> 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.
> 
Then dropped.

thanks
Hillf

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web