All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: David Rientjes <rientjes@google.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 10:48:01 +0100	[thread overview]
Message-ID: <56A9E3D1.3090001@de.ibm.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1601271414180.23510@chino.kir.corp.google.com>

On 01/27/2016 11:17 PM, David Rientjes wrote:
> On Wed, 27 Jan 2016, Christian Borntraeger wrote:
> 
>> We can use debug_pagealloc_enabled() to check if we can map
>> the identity mapping with 2MB pages. We can also add the state
>> into the dump_stack output.
>>
>> The patch does not touch the code for the 1GB pages, which ignored
>> CONFIG_DEBUG_PAGEALLOC. Do we need to fence this as well?
>>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
>> ---
>>  arch/x86/kernel/dumpstack.c |  5 ++---
>>  arch/x86/mm/init.c          |  7 ++++---
>>  arch/x86/mm/pageattr.c      | 14 ++++----------
>>  3 files changed, 10 insertions(+), 16 deletions(-)
>>
>> diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
>> index 9c30acf..32e5699 100644
>> --- a/arch/x86/kernel/dumpstack.c
>> +++ b/arch/x86/kernel/dumpstack.c
>> @@ -265,9 +265,8 @@ int __die(const char *str, struct pt_regs *regs, long err)
>>  #ifdef CONFIG_SMP
>>  	printk("SMP ");
>>  #endif
>> -#ifdef CONFIG_DEBUG_PAGEALLOC
>> -	printk("DEBUG_PAGEALLOC ");
>> -#endif
>> +	if (debug_pagealloc_enabled())
>> +		printk("DEBUG_PAGEALLOC ");
>>  #ifdef CONFIG_KASAN
>>  	printk("KASAN");
>>  #endif
>> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
>> index 493f541..39823fd 100644
>> --- a/arch/x86/mm/init.c
>> +++ b/arch/x86/mm/init.c
>> @@ -150,13 +150,14 @@ static int page_size_mask;
>>  
>>  static void __init probe_page_size_mask(void)
>>  {
>> -#if !defined(CONFIG_DEBUG_PAGEALLOC) && !defined(CONFIG_KMEMCHECK)
>> +#if !defined(CONFIG_KMEMCHECK)
>>  	/*
>> -	 * For CONFIG_DEBUG_PAGEALLOC, identity mapping will use small pages.
>> +	 * For CONFIG_KMEMCHECK or pagealloc debugging, identity mapping will
>> +	 * use small pages.
>>  	 * This will simplify cpa(), which otherwise needs to support splitting
>>  	 * large pages into small in interrupt context, etc.
>>  	 */
>> -	if (cpu_has_pse)
>> +	if (cpu_has_pse && !debug_pagealloc_enabled())
>>  		page_size_mask |= 1 << PG_LEVEL_2M;
>>  #endif
>>  
> 
> I would have thought free_init_pages() would be modified to use 
> debug_pagealloc_enabled() as well?


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.

WARNING: multiple messages have this Message-ID (diff)
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: David Rientjes <rientjes@google.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 10:48:01 +0100	[thread overview]
Message-ID: <56A9E3D1.3090001@de.ibm.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1601271414180.23510@chino.kir.corp.google.com>

On 01/27/2016 11:17 PM, David Rientjes wrote:
> On Wed, 27 Jan 2016, Christian Borntraeger wrote:
> 
>> We can use debug_pagealloc_enabled() to check if we can map
>> the identity mapping with 2MB pages. We can also add the state
>> into the dump_stack output.
>>
>> The patch does not touch the code for the 1GB pages, which ignored
>> CONFIG_DEBUG_PAGEALLOC. Do we need to fence this as well?
>>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
>> ---
>>  arch/x86/kernel/dumpstack.c |  5 ++---
>>  arch/x86/mm/init.c          |  7 ++++---
>>  arch/x86/mm/pageattr.c      | 14 ++++----------
>>  3 files changed, 10 insertions(+), 16 deletions(-)
>>
>> diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
>> index 9c30acf..32e5699 100644
>> --- a/arch/x86/kernel/dumpstack.c
>> +++ b/arch/x86/kernel/dumpstack.c
>> @@ -265,9 +265,8 @@ int __die(const char *str, struct pt_regs *regs, long err)
>>  #ifdef CONFIG_SMP
>>  	printk("SMP ");
>>  #endif
>> -#ifdef CONFIG_DEBUG_PAGEALLOC
>> -	printk("DEBUG_PAGEALLOC ");
>> -#endif
>> +	if (debug_pagealloc_enabled())
>> +		printk("DEBUG_PAGEALLOC ");
>>  #ifdef CONFIG_KASAN
>>  	printk("KASAN");
>>  #endif
>> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
>> index 493f541..39823fd 100644
>> --- a/arch/x86/mm/init.c
>> +++ b/arch/x86/mm/init.c
>> @@ -150,13 +150,14 @@ static int page_size_mask;
>>  
>>  static void __init probe_page_size_mask(void)
>>  {
>> -#if !defined(CONFIG_DEBUG_PAGEALLOC) && !defined(CONFIG_KMEMCHECK)
>> +#if !defined(CONFIG_KMEMCHECK)
>>  	/*
>> -	 * For CONFIG_DEBUG_PAGEALLOC, identity mapping will use small pages.
>> +	 * For CONFIG_KMEMCHECK or pagealloc debugging, identity mapping will
>> +	 * use small pages.
>>  	 * This will simplify cpa(), which otherwise needs to support splitting
>>  	 * large pages into small in interrupt context, etc.
>>  	 */
>> -	if (cpu_has_pse)
>> +	if (cpu_has_pse && !debug_pagealloc_enabled())
>>  		page_size_mask |= 1 << PG_LEVEL_2M;
>>  #endif
>>  
> 
> I would have thought free_init_pages() would be modified to use 
> debug_pagealloc_enabled() as well?


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.


--
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-01-28  9:48 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 [this message]
2016-01-28  9:48       ` Christian Borntraeger
2016-01-28 23:03       ` David Rientjes
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=56A9E3D1.3090001@de.ibm.com \
    --to=borntraeger@de.ibm.com \
    --cc=akpm@linux-foundation.org \
    --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=rientjes@google.com \
    --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.