From: Mel Gorman <mgorman@techsingularity.net>
To: Vinayak Menon <vinmenon@codeaurora.org>
Cc: Linux-MM <linux-mm@kvack.org>,
hannes@cmpxchg.org, Andrew Morton <akpm@linux-foundation.org>,
mhocko@suse.com, Minchan Kim <minchan@kernel.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
"vbabka@suse.cz" <vbabka@suse.cz>
Subject: Re: [RFC] kswapd aggressiveness with watermark_scale_factor
Date: Wed, 7 Mar 2018 10:18:10 +0000 [thread overview]
Message-ID: <20180307101810.sxnd4tqijbatp22d@techsingularity.net> (raw)
In-Reply-To: <0467b068-4627-e49f-77e8-c785a38a0d74@codeaurora.org>
On Wed, Mar 07, 2018 at 02:47:09PM +0530, Vinayak Menon wrote:
> > This needs a proper changelog, signed-offs and a comment on the reasoning
> > behind the new min value for the gap between low and high and how it
> > was derived. It appears the equation was designed such at the gap, as
> > a percentage of the zone size, would shrink according as the zone size
> > increases but I'm not 100% certain that was the intent. That should be
> > explained and why not just using "tmp >> 2" would have problems.
> >
> > It would also need review/testing by Johannes to ensure that there is no
> > reintroduction of the problems that watermark_scale_factor was designed
> > to solve.
>
> Sorry for the delayed response. I will send a patch with the details. The equation was designed so that the
> low-high gap is small for smaller RAM sizes and tends towards min-low gap as the RAM size increases. This
> was done considering that it should not have a bad effect on for 140G configuration which Johannes had taken
> taken as example when watermark_scale_factor was introduced, also assuming that the thrashing seen due to
> low-high gap would be visible only on low RAM devices.
>
If you do spin a new version with corrections made, be very careful to
note that the figures you supply are based on a kernel without THP because
that's where it makes a real difference. The differences with THP enabled
are very different as that alters min_free_kbytes and by extention, it
changes the point where your patch has an effect on the distance between
watermarks. It does mean that a test you say definitely works will not
necessary be visible to someone who tests the same patch on x86-64. Maybe
no one will notice or care but if you get a report about the results being
unreproducible then I suggest you check first if THP was enabled.
--
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>
next prev parent reply other threads:[~2018-03-07 10:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-24 15:55 Vinayak Menon
2018-01-29 11:21 ` Vinayak Menon
2018-02-15 12:40 ` Mel Gorman
2018-03-07 9:17 ` Vinayak Menon
2018-03-07 10:18 ` Mel Gorman [this message]
2018-03-07 10:26 ` Vinayak Menon
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=20180307101810.sxnd4tqijbatp22d@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=minchan@kernel.org \
--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