From: David Rientjes <rientjes@google.com>
To: Charan Teja Reddy <charante@codeaurora.org>
Cc: akpm@linux-foundation.org, vbabka@suse.cz, mhocko@suse.com,
khalid.aziz@oracle.com, ngupta@nitingupta.dev,
vinmenon@codeaurora.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH V3] mm/compaction: correct deferral logic for proactive compaction
Date: Tue, 19 Jan 2021 11:26:08 -0800 (PST) [thread overview]
Message-ID: <af22a056-5c27-256f-74d-63de8fd33084@google.com> (raw)
In-Reply-To: <1610989938-31374-1-git-send-email-charante@codeaurora.org>
On Mon, 18 Jan 2021, Charan Teja Reddy wrote:
> should_proactive_compact_node() returns true when sum of the
> weighted fragmentation score of all the zones in the node is greater
> than the wmark_high of compaction, which then triggers the proactive
> compaction that operates on the individual zones of the node. But
> proactive compaction runs on the zone only when its weighted
> fragmentation score is greater than wmark_low(=wmark_high - 10).
>
> This means that the sum of the weighted fragmentation scores of all the
> zones can exceed the wmark_high but individual weighted fragmentation
> zone scores can still be less than wmark_low which makes the unnecessary
> trigger of the proactive compaction only to return doing nothing.
>
> Issue with the return of proactive compaction with out even trying is
> its deferral. It is simply deferred for 1 << COMPACT_MAX_DEFER_SHIFT if
> the scores across the proactive compaction is same, thinking that
> compaction didn't make any progress but in reality it didn't even try.
Isn't this an issue in deferred compaction as well? It seems like
deferred compaction should check that work was actually performed before
deferring subsequent calls to compaction.
In other words, I don't believe deferred compaction is intended to avoid
checks to determine if compaction is worth it; it should only defer
*additional* work that was not productive.
Thoughts?
> With the delay between successive retries for proactive compaction is
> 500msec, it can result into the deferral for ~30sec with out even trying
> the proactive compaction.
>
> Test scenario is that: compaction_proactiveness=50 thus the wmark_low =
> 50 and wmark_high = 60. System have 2 zones(Normal and Movable) with
> sizes 5GB and 6GB respectively. After opening some apps on the android,
> the weighted fragmentation scores of these zones are 47 and 49
> respectively. Since the sum of these fragmentation scores are above the
> wmark_high which triggers the proactive compaction and there since the
> individual zones weighted fragmentation scores are below wmark_low, it
> returns without trying the proactive compaction. As a result the
> weighted fragmentation scores of the zones are still 47 and 49 which
> makes the existing logic to defer the compaction thinking that
> noprogress is made across the compaction.
>
> Fix this by checking just zone fragmentation score, not the weighted, in
> __compact_finished() and use the zones weighted fragmentation score in
> fragmentation_score_node(). In the test case above, If the weighted
> average of is above wmark_high, then individual score (not adjusted) of
> atleast one zone has to be above wmark_high. Thus it avoids the
> unnecessary trigger and deferrals of the proactive compaction.
>
> Fix-suggested-by: Vlastimil Babka <vbabka@suse.cz>
Suggested-by
> Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
Acked-by: David Rientjes <rientjes@google.com>
next prev parent reply other threads:[~2021-01-19 19:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-18 17:12 Charan Teja Reddy
2021-01-18 17:41 ` Vlastimil Babka
2021-01-19 15:42 ` Khalid Aziz
2021-01-19 19:26 ` David Rientjes [this message]
2021-01-20 11:04 ` Vlastimil Babka
2021-01-24 22:54 ` David Rientjes
2021-01-27 15:47 ` Charan Teja Kalla
2021-01-25 15:56 ` Vlastimil Babka
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=af22a056-5c27-256f-74d-63de8fd33084@google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=charante@codeaurora.org \
--cc=khalid.aziz@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=ngupta@nitingupta.dev \
--cc=vbabka@suse.cz \
--cc=vinmenon@codeaurora.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox