From: David Rientjes <rientjes@google.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-arch@vger.kernel.org,
linux-s390@vger.kernel.org, x86@kernel.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
davej@codemonkey.org.uk
Subject: Re: [PATCH v3 2/3] x86: query dynamic DEBUG_PAGEALLOC setting
Date: Thu, 28 Jan 2016 15:03:39 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.10.1601281500160.31035@chino.kir.corp.google.com> (raw)
In-Reply-To: <56A9E3D1.3090001@de.ibm.com>
On Thu, 28 Jan 2016, Christian Borntraeger wrote:
> Indeed, I only touched the identity mapping and dump stack.
> The question is do we really want to change free_init_pages as well?
> The unmapping during runtime causes significant overhead, but the
> unmapping after init imposes almost no runtime overhead. Of course,
> things get fishy now as what is enabled and what not.
>
> Kconfig after my patch "mm/debug_pagealloc: Ask users for default setting of debug_pagealloc"
> (in mm) now states
> ----snip----
> By default this option will have a small overhead, e.g. by not
> allowing the kernel mapping to be backed by large pages on some
> architectures. Even bigger overhead comes when the debugging is
> enabled by DEBUG_PAGEALLOC_ENABLE_DEFAULT or the debug_pagealloc
> command line parameter.
> ----snip----
>
> So I am tempted to NOT change free_init_pages, but the x86 maintainers
> can certainly decide differently. Ingo, Thomas, H. Peter, please advise.
>
I'm sorry, but I thought the discussion of the previous version of the
patchset led to deciding that all CONFIG_DEBUG_PAGEALLOC behavior would be
controlled by being enabled on the commandline and checked with
debug_pagealloc_enabled().
I don't think we should have a CONFIG_DEBUG_PAGEALLOC that does some stuff
and then a commandline parameter or CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT
to enable more stuff. It should either be all enabled by the commandline
(or config option) or split into a separate entity.
CONFIG_DEBUG_PAGEALLOC_LIGHT and CONFIG_DEBUG_PAGEALLOC would be fine, but
the current state is very confusing about what is being done and what
isn't.
It also wouldn't hurt to enumerate what is enabled and what isn't enabled
in the Kconfig entry.
WARNING: multiple messages have this Message-ID (diff)
From: David Rientjes <rientjes@google.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-arch@vger.kernel.org,
linux-s390@vger.kernel.org, x86@kernel.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
davej@codemonkey.org.uk
Subject: Re: [PATCH v3 2/3] x86: query dynamic DEBUG_PAGEALLOC setting
Date: Thu, 28 Jan 2016 15:03:39 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.10.1601281500160.31035@chino.kir.corp.google.com> (raw)
In-Reply-To: <56A9E3D1.3090001@de.ibm.com>
On Thu, 28 Jan 2016, Christian Borntraeger wrote:
> Indeed, I only touched the identity mapping and dump stack.
> The question is do we really want to change free_init_pages as well?
> The unmapping during runtime causes significant overhead, but the
> unmapping after init imposes almost no runtime overhead. Of course,
> things get fishy now as what is enabled and what not.
>
> Kconfig after my patch "mm/debug_pagealloc: Ask users for default setting of debug_pagealloc"
> (in mm) now states
> ----snip----
> By default this option will have a small overhead, e.g. by not
> allowing the kernel mapping to be backed by large pages on some
> architectures. Even bigger overhead comes when the debugging is
> enabled by DEBUG_PAGEALLOC_ENABLE_DEFAULT or the debug_pagealloc
> command line parameter.
> ----snip----
>
> So I am tempted to NOT change free_init_pages, but the x86 maintainers
> can certainly decide differently. Ingo, Thomas, H. Peter, please advise.
>
I'm sorry, but I thought the discussion of the previous version of the
patchset led to deciding that all CONFIG_DEBUG_PAGEALLOC behavior would be
controlled by being enabled on the commandline and checked with
debug_pagealloc_enabled().
I don't think we should have a CONFIG_DEBUG_PAGEALLOC that does some stuff
and then a commandline parameter or CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT
to enable more stuff. It should either be all enabled by the commandline
(or config option) or split into a separate entity.
CONFIG_DEBUG_PAGEALLOC_LIGHT and CONFIG_DEBUG_PAGEALLOC would be fine, but
the current state is very confusing about what is being done and what
isn't.
It also wouldn't hurt to enumerate what is enabled and what isn't enabled
in the Kconfig entry.
--
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:[~2016-01-28 23:03 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-27 10:09 [PATCH v3 0/3] Optimize CONFIG_DEBUG_PAGEALLOC Christian Borntraeger
2016-01-27 10:09 ` Christian Borntraeger
2016-01-27 10:09 ` [PATCH v3 1/3] mm: provide debug_pagealloc_enabled() without CONFIG_DEBUG_PAGEALLOC Christian Borntraeger
2016-01-27 10:09 ` Christian Borntraeger
2016-01-27 10:10 ` [PATCH v3 2/3] x86: query dynamic DEBUG_PAGEALLOC setting Christian Borntraeger
2016-01-27 10:10 ` Christian Borntraeger
2016-01-27 22:17 ` David Rientjes
2016-01-27 22:17 ` David Rientjes
2016-01-28 9:48 ` Christian Borntraeger
2016-01-28 9:48 ` Christian Borntraeger
2016-01-28 23:03 ` David Rientjes [this message]
2016-01-28 23:03 ` David Rientjes
2016-02-02 21:51 ` David Rientjes
2016-02-02 21:51 ` David Rientjes
2016-02-02 21:53 ` Christian Borntraeger
2016-02-02 21:53 ` Christian Borntraeger
2016-02-02 22:21 ` Andrew Morton
2016-02-02 22:21 ` Andrew Morton
2016-02-02 22:37 ` Christian Borntraeger
2016-02-02 22:37 ` Christian Borntraeger
2016-02-02 23:04 ` Andrew Morton
2016-02-02 23:04 ` Andrew Morton
2016-02-03 0:13 ` Stephen Rothwell
2016-02-03 0:13 ` Stephen Rothwell
2016-02-02 21:52 ` (unknown) David Rientjes via Linuxppc-dev
2016-01-28 23:04 ` (unknown) David Rientjes via Linuxppc-dev
2016-01-27 22:18 ` (unknown) David Rientjes via Linuxppc-dev
2016-01-27 10:10 ` [PATCH v3 3/3] s390: query dynamic DEBUG_PAGEALLOC setting Christian Borntraeger
2016-01-27 10:10 ` Christian Borntraeger
2016-01-27 22:18 ` David Rientjes
2016-01-27 22:18 ` David Rientjes
2016-01-27 22:22 ` (unknown) David Rientjes via Linuxppc-dev
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=alpine.DEB.2.10.1601281500160.31035@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=borntraeger@de.ibm.com \
--cc=davej@codemonkey.org.uk \
--cc=davem@davemloft.net \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=x86@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 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.