All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Jason Baron <jbaron@akamai.com>
Cc: akpm@linux-foundation.org, kirill.shutemov@linux.intel.com,
	rientjes@google.com, aarcange@redhat.com,
	mgorman@techsingularity.net, mhocko@suse.com, hannes@cmpxchg.org,
	vbabka@suse.cz, linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] mm: update min_free_kbytes from khugepaged after core initialization
Date: Wed, 13 Apr 2016 13:36:27 +0300	[thread overview]
Message-ID: <20160413103627.GA5051@node.shutemov.name> (raw)
In-Reply-To: <2bd05bd3f581116cee2d6396ea72613cf217a8c5.1460488349.git.jbaron@akamai.com>

On Tue, Apr 12, 2016 at 03:54:37PM -0400, Jason Baron wrote:
> Khugepaged attempts to raise min_free_kbytes if its set too low. However,
> on boot khugepaged sets min_free_kbytes first from subsys_initcall(), and
> then the mm 'core' over-rides min_free_kbytes after from
> init_per_zone_wmark_min(), via a module_init() call.
> 
> Khugepaged used to use a late_initcall() to set min_free_kbytes (such that
> it occurred after the core initialization), however this was removed when
> the initialization of min_free_kbytes was integrated into the starting of
> the khugepaged thread.
> 
> The fix here is simply to invoke the core initialization using a
> core_initcall() instead of module_init(), such that the previous
> initialization ordering is restored. I didn't restore the late_initcall()
> since start_stop_khugepaged() already sets min_free_kbytes via
> set_recommended_min_free_kbytes().
> 
> This was noticed when we had a number of page allocation failures when
> moving a workload to a kernel with this new initialization ordering. On an
> 8GB system this restores min_free_kbytes back to 67584 from 11365 when
> CONFIG_TRANSPARENT_HUGEPAGE=y is set and either
> CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y or
> CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.
> 
> Fixes: 79553da293d3 ("thp: cleanup khugepaged startup")
> Signed-off-by: Jason Baron <jbaron@akamai.com>

Looks good to me:

Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>

-- 
 Kirill A. Shutemov

WARNING: multiple messages have this Message-ID (diff)
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Jason Baron <jbaron@akamai.com>
Cc: akpm@linux-foundation.org, kirill.shutemov@linux.intel.com,
	rientjes@google.com, aarcange@redhat.com,
	mgorman@techsingularity.net, mhocko@suse.com, hannes@cmpxchg.org,
	vbabka@suse.cz, linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] mm: update min_free_kbytes from khugepaged after core initialization
Date: Wed, 13 Apr 2016 13:36:27 +0300	[thread overview]
Message-ID: <20160413103627.GA5051@node.shutemov.name> (raw)
In-Reply-To: <2bd05bd3f581116cee2d6396ea72613cf217a8c5.1460488349.git.jbaron@akamai.com>

On Tue, Apr 12, 2016 at 03:54:37PM -0400, Jason Baron wrote:
> Khugepaged attempts to raise min_free_kbytes if its set too low. However,
> on boot khugepaged sets min_free_kbytes first from subsys_initcall(), and
> then the mm 'core' over-rides min_free_kbytes after from
> init_per_zone_wmark_min(), via a module_init() call.
> 
> Khugepaged used to use a late_initcall() to set min_free_kbytes (such that
> it occurred after the core initialization), however this was removed when
> the initialization of min_free_kbytes was integrated into the starting of
> the khugepaged thread.
> 
> The fix here is simply to invoke the core initialization using a
> core_initcall() instead of module_init(), such that the previous
> initialization ordering is restored. I didn't restore the late_initcall()
> since start_stop_khugepaged() already sets min_free_kbytes via
> set_recommended_min_free_kbytes().
> 
> This was noticed when we had a number of page allocation failures when
> moving a workload to a kernel with this new initialization ordering. On an
> 8GB system this restores min_free_kbytes back to 67584 from 11365 when
> CONFIG_TRANSPARENT_HUGEPAGE=y is set and either
> CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y or
> CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.
> 
> Fixes: 79553da293d3 ("thp: cleanup khugepaged startup")
> Signed-off-by: Jason Baron <jbaron@akamai.com>

Looks good to me:

Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>

-- 
 Kirill A. Shutemov

--
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:[~2016-04-13 10:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-12 19:54 [PATCH 0/1] mm: setting of min_free_kbytes Jason Baron
2016-04-12 19:54 ` Jason Baron
2016-04-12 19:54 ` [PATCH 1/1] mm: update min_free_kbytes from khugepaged after core initialization Jason Baron
2016-04-12 19:54   ` Jason Baron
2016-04-13 10:36   ` Kirill A. Shutemov [this message]
2016-04-13 10:36     ` Kirill A. Shutemov
2016-04-14 20:08   ` David Rientjes
2016-04-14 20:08     ` David Rientjes

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=20160413103627.GA5051@node.shutemov.name \
    --to=kirill@shutemov.name \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=jbaron@akamai.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@suse.com \
    --cc=rientjes@google.com \
    --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 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.