From: Mel Gorman <mgorman@suse.de>
To: Sultan Alsawaf <sultan@kerneltoast.com>
Cc: Michal Hocko <mhocko@kernel.org>,
Dave Hansen <dave.hansen@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [PATCH] mm: Stop kswapd early when nothing's waiting for it to free pages
Date: Wed, 19 Feb 2020 21:45:13 +0000 [thread overview]
Message-ID: <20200219214513.GL3420@suse.de> (raw)
In-Reply-To: <20200219204220.GA3488@sultan-book.localdomain>
On Wed, Feb 19, 2020 at 12:42:20PM -0800, Sultan Alsawaf wrote:
> > Again, do you have more details about the workload and what was the
> > cause of responsiveness issues? Because I would expect that the
> > situation would be quite opposite because it is usually the direct
> > reclaim that is a source of stalls visible from userspace. Or is this
> > about a single CPU situation where kswapd saturates the single CPU and
> > all other tasks are just not getting enough CPU cycles?
>
> The workload was having lots of applications open at once. At a certain point
> when memory ran low, my system became sluggish and kswapd CPU usage skyrocketed.
> I added printks into kswapd with this patch, and my premature exit in kswapd
> kicked in quite often.
>
This could be watermark boosting run wild again. Can you test with
sysctl vm.watermark_boost_factor=0 or the following patch? (preferably
both to compare and contrast).
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 572fb17c6273..71dd47172cef 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3462,6 +3462,25 @@ static bool pgdat_balanced(pg_data_t *pgdat, int order, int classzone_idx)
return false;
}
+static void acct_boosted_reclaim(pg_data_t *pgdat, int classzone_idx,
+ unsigned long *zone_boosts)
+{
+ struct zone *zone;
+ unsigned long flags;
+ int i;
+
+ for (i = 0; i <= classzone_idx; i++) {
+ if (!zone_boosts[i])
+ continue;
+
+ /* Increments are under the zone lock */
+ zone = pgdat->node_zones + i;
+ spin_lock_irqsave(&zone->lock, flags);
+ zone->watermark_boost -= min(zone->watermark_boost, zone_boosts[i]);
+ spin_unlock_irqrestore(&zone->lock, flags);
+ }
+}
+
/* Clear pgdat state for congested, dirty or under writeback. */
static void clear_pgdat_congested(pg_data_t *pgdat)
{
@@ -3654,9 +3673,17 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx)
if (!nr_boost_reclaim && balanced)
goto out;
- /* Limit the priority of boosting to avoid reclaim writeback */
- if (nr_boost_reclaim && sc.priority == DEF_PRIORITY - 2)
- raise_priority = false;
+ /*
+ * Abort boosting if reclaiming at higher priority is not
+ * working to avoid excessive reclaim due to lower zones
+ * being boosted.
+ */
+ if (nr_boost_reclaim && sc.priority == DEF_PRIORITY - 2) {
+ acct_boosted_reclaim(pgdat, classzone_idx, zone_boosts);
+ boosted = false;
+ nr_boost_reclaim = 0;
+ goto restart;
+ }
/*
* Do not writeback or swap pages for boosted reclaim. The
@@ -3738,18 +3765,7 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx)
out:
/* If reclaim was boosted, account for the reclaim done in this pass */
if (boosted) {
- unsigned long flags;
-
- for (i = 0; i <= classzone_idx; i++) {
- if (!zone_boosts[i])
- continue;
-
- /* Increments are under the zone lock */
- zone = pgdat->node_zones + i;
- spin_lock_irqsave(&zone->lock, flags);
- zone->watermark_boost -= min(zone->watermark_boost, zone_boosts[i]);
- spin_unlock_irqrestore(&zone->lock, flags);
- }
+ acct_boosted_reclaim(pgdat, classzone_idx, zone_boosts);
/*
* As there is now likely space, wakeup kcompact to defragment
next prev parent reply other threads:[~2020-02-19 21:45 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-19 18:25 [PATCH] mm: Stop kswapd early when nothing's waiting for it to free pages Sultan Alsawaf
2020-02-19 18:25 ` Sultan Alsawaf
2020-02-19 19:13 ` Dave Hansen
2020-02-19 19:40 ` Sultan Alsawaf
2020-02-19 20:05 ` Michal Hocko
2020-02-19 20:42 ` Sultan Alsawaf
2020-02-19 21:45 ` Mel Gorman [this message]
2020-02-19 22:42 ` Sultan Alsawaf
2020-02-20 10:19 ` Mel Gorman
2020-02-21 4:22 ` Sultan Alsawaf
2020-02-21 8:07 ` Michal Hocko
[not found] ` <20200221210824.GA3605@sultan-book.localdomain>
2020-02-21 21:24 ` Dave Hansen
2020-02-25 9:09 ` Michal Hocko
2020-02-25 17:12 ` Sultan Alsawaf
2020-02-26 9:05 ` Michal Hocko
2020-02-25 22:30 ` Shakeel Butt
2020-02-26 9:08 ` Michal Hocko
2020-02-26 17:00 ` Shakeel Butt
2020-02-26 17:41 ` Michal Hocko
2020-02-26 10:51 ` Hillf Danton
2020-02-26 17:04 ` Shakeel Butt
2020-02-27 1:48 ` Hillf Danton
2020-02-21 18:04 ` Shakeel Butt
2020-02-21 20:06 ` Sultan Alsawaf
2020-02-20 8:29 ` Michal Hocko
2020-02-19 19:26 ` Andrew Morton
2020-02-19 22:45 ` Sultan Alsawaf
2020-02-19 19:35 ` Michal Hocko
2020-02-21 4:30 ` [PATCH v2] " Sultan Alsawaf
2020-02-21 4:30 ` Sultan Alsawaf
2020-02-21 18:22 ` Ira Weiny
2020-02-21 20:00 ` Sultan Alsawaf
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=20200219214513.GL3420@suse.de \
--to=mgorman@suse.de \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=sultan@kerneltoast.com \
/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.