From: Sultan Alsawaf <sultan@kerneltoast.com>
To: Mel Gorman <mgorman@suse.de>
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 14:42:31 -0800 [thread overview]
Message-ID: <20200219224231.GA5190@sultan-book.localdomain> (raw)
In-Reply-To: <20200219214513.GL3420@suse.de>
On Wed, Feb 19, 2020 at 09:45:13PM +0000, Mel Gorman wrote:
> 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).
I can test that, but something to note is that I've been doing equal testing
with this on 4.4, which exhibits the same behavior, and that kernel doesn't have
watermark boosting in it, as far as I can tell.
I don't think what we're addressing here is a "bug", but rather something
fundamental about how we've been thinking about kswapd lifetime. The argument
here is that it's not coherent to be letting kswapd run as it does, and instead
gating it on outstanding allocation requests provides much more reasonable
behavior, given real workloads and use patterns.
Does that make sense and seem reasonable?
Sultan
next prev parent reply other threads:[~2020-02-19 22:42 UTC|newest]
Thread overview: 27+ 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 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
2020-02-19 22:42 ` Sultan Alsawaf [this message]
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
[not found] ` <20200226105137.9088-1-hdanton@sina.com>
2020-02-26 17:04 ` Shakeel Butt
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
[not found] ` <20200221182201.GB4462@iweiny-DESK2.sc.intel.com>
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=20200219224231.GA5190@sultan-book.localdomain \
--to=sultan@kerneltoast.com \
--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=mgorman@suse.de \
--cc=mhocko@kernel.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;
as well as URLs for NNTP newsgroup(s).