From: Mel Gorman <mgorman@techsingularity.net>
To: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: 'Andrew Morton' <akpm@linux-foundation.org>,
'Johannes Weiner' <hannes@cmpxchg.org>,
'Vlastimil Babka' <vbabka@suse.cz>,
'linux-kernel' <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org
Subject: Re: [PATCH] mm, vmscan: Give up balancing node for high order allocations earlier
Date: Tue, 12 Jul 2016 09:33:42 +0100 [thread overview]
Message-ID: <20160712083342.GC9806@techsingularity.net> (raw)
In-Reply-To: <013d01d1dc07$33896860$9a9c3920$@alibaba-inc.com>
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
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@techsingularity.net>
To: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: "'Andrew Morton'" <akpm@linux-foundation.org>,
"'Johannes Weiner'" <hannes@cmpxchg.org>,
"'Vlastimil Babka'" <vbabka@suse.cz>,
"'linux-kernel'" <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org
Subject: Re: [PATCH] mm, vmscan: Give up balancing node for high order allocations earlier
Date: Tue, 12 Jul 2016 09:33:42 +0100 [thread overview]
Message-ID: <20160712083342.GC9806@techsingularity.net> (raw)
In-Reply-To: <013d01d1dc07$33896860$9a9c3920$@alibaba-inc.com>
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
next prev parent reply other threads:[~2016-07-12 8:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-29 5:42 [PATCH] mm, vmscan: Give up balancing node for high order allocations earlier Hillf Danton
2016-06-29 5:42 ` Hillf Danton
2016-07-11 22:20 ` Andrew Morton
2016-07-11 22:20 ` Andrew Morton
2016-07-12 6:32 ` Hillf Danton
2016-07-12 6:32 ` Hillf Danton
2016-07-12 8:33 ` Mel Gorman [this message]
2016-07-12 8:33 ` Mel Gorman
2016-07-12 8:48 ` Hillf Danton
2016-07-12 8:48 ` Hillf Danton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160712083342.GC9806@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=hillf.zj@alibaba-inc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.