linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vinayak Menon <vinmenon@codeaurora.org>
To: Mel Gorman <mgorman@techsingularity.net>
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 15:56:24 +0530	[thread overview]
Message-ID: <0877c272-9011-6e0d-c8c1-894959ad5645@codeaurora.org> (raw)
In-Reply-To: <20180307101810.sxnd4tqijbatp22d@techsingularity.net>

On 3/7/2018 3:48 PM, Mel Gorman wrote:
> 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.

Sure. The results provided earlier were without THP.

--
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>

      reply	other threads:[~2018-03-07 10:26 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
2018-03-07 10:26       ` Vinayak Menon [this message]

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=0877c272-9011-6e0d-c8c1-894959ad5645@codeaurora.org \
    --to=vinmenon@codeaurora.org \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@suse.com \
    --cc=minchan@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox