From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org,
akpm@linux-foundation.org, linux-mm@kvack.org,
Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [PATCH] mm/debug_pagealloc: Ask users for default setting of debug_pagealloc
Date: Mon, 25 Jan 2016 11:07:04 +0100 [thread overview]
Message-ID: <56A5F3C8.4050202@de.ibm.com> (raw)
In-Reply-To: <20160125100248.GB4298@osiris>
On 01/25/2016 11:02 AM, Heiko Carstens wrote:
> On Mon, Jan 25, 2016 at 10:45:50AM +0100, Christian Borntraeger wrote:
>>>> + By default this option will be almost for free and can be activated
>>>> + in distribution kernels. The overhead and the debugging can be enabled
>>>> + by DEBUG_PAGEALLOC_ENABLE_DEFAULT or the debug_pagealloc command line
>>>> + parameter.
>>>
>>> Sorry, but it's not almost for free and should not be used by distribution
>>> kernels. If we have DEBUG_PAGEALLOC enabled, at least on s390 we will not
>>> make use of 2GB and 1MB pagetable entries for the identy mapping anymore.
>>> Instead we will only use 4K mappings.
>>
>> Hmmm, can we change these code areas to use debug_pagealloc_enabled? I guess
>> this evaluated too late?
>
> Yes, that should be possible. "debug_pagealloc" is an early_param, which
> will be evaluated before we call paging_init() (both in
> arch/s390/kernel/setup.c).
>
> So it looks like this can be trivially changed. (replace the ifdefs in
> arch/s390/mm/vmem.c with debug_pagealloc_enabled()).
>
>>> I assume this is true for all architectures since freeing pages can happen
>>> in any context and therefore we can't allocate memory in order to split
>>> page tables.
>>>
>>> So enabling this will cost memory and put more pressure on the TLB.
>>
>> So I will change the description and drop the "if unsure" statement.
>
> Well, given that we can change it like above... I don't care anymore ;)
Ok, I will give it a try, and come back with a rewording or an s390 patch.
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org,
akpm@linux-foundation.org, linux-mm@kvack.org,
Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [PATCH] mm/debug_pagealloc: Ask users for default setting of debug_pagealloc
Date: Mon, 25 Jan 2016 11:07:04 +0100 [thread overview]
Message-ID: <56A5F3C8.4050202@de.ibm.com> (raw)
In-Reply-To: <20160125100248.GB4298@osiris>
On 01/25/2016 11:02 AM, Heiko Carstens wrote:
> On Mon, Jan 25, 2016 at 10:45:50AM +0100, Christian Borntraeger wrote:
>>>> + By default this option will be almost for free and can be activated
>>>> + in distribution kernels. The overhead and the debugging can be enabled
>>>> + by DEBUG_PAGEALLOC_ENABLE_DEFAULT or the debug_pagealloc command line
>>>> + parameter.
>>>
>>> Sorry, but it's not almost for free and should not be used by distribution
>>> kernels. If we have DEBUG_PAGEALLOC enabled, at least on s390 we will not
>>> make use of 2GB and 1MB pagetable entries for the identy mapping anymore.
>>> Instead we will only use 4K mappings.
>>
>> Hmmm, can we change these code areas to use debug_pagealloc_enabled? I guess
>> this evaluated too late?
>
> Yes, that should be possible. "debug_pagealloc" is an early_param, which
> will be evaluated before we call paging_init() (both in
> arch/s390/kernel/setup.c).
>
> So it looks like this can be trivially changed. (replace the ifdefs in
> arch/s390/mm/vmem.c with debug_pagealloc_enabled()).
>
>>> I assume this is true for all architectures since freeing pages can happen
>>> in any context and therefore we can't allocate memory in order to split
>>> page tables.
>>>
>>> So enabling this will cost memory and put more pressure on the TLB.
>>
>> So I will change the description and drop the "if unsure" statement.
>
> Well, given that we can change it like above... I don't care anymore ;)
Ok, I will give it a try, and come back with a rewording or an s390 patch.
next prev parent reply other threads:[~2016-01-25 10:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-25 9:19 [PATCH] mm/debug_pagealloc: Ask users for default setting of debug_pagealloc Christian Borntraeger
2016-01-25 9:19 ` Christian Borntraeger
2016-01-25 9:41 ` Heiko Carstens
2016-01-25 9:41 ` Heiko Carstens
2016-01-25 9:45 ` Christian Borntraeger
2016-01-25 9:45 ` Christian Borntraeger
2016-01-25 10:02 ` Heiko Carstens
2016-01-25 10:02 ` Heiko Carstens
2016-01-25 10:07 ` Christian Borntraeger [this message]
2016-01-25 10:07 ` Christian Borntraeger
2016-01-25 11:10 ` Christian Borntraeger
2016-01-25 11:10 ` Christian Borntraeger
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=56A5F3C8.4050202@de.ibm.com \
--to=borntraeger@de.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=heiko.carstens@de.ibm.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterz@infradead.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.