From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754544AbcBBVxw (ORCPT ); Tue, 2 Feb 2016 16:53:52 -0500 Received: from e06smtp08.uk.ibm.com ([195.75.94.104]:43668 "EHLO e06smtp08.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751837AbcBBVxt (ORCPT ); Tue, 2 Feb 2016 16:53:49 -0500 X-IBM-Helo: d06dlp03.portsmouth.uk.ibm.com X-IBM-MailFrom: borntraeger@de.ibm.com X-IBM-RcptTo: linux-arch@vger.kernel.org;linux-kernel@vger.kernel.org;linux-s390@vger.kernel.org Subject: Re: [PATCH v3 2/3] x86: query dynamic DEBUG_PAGEALLOC setting To: David Rientjes References: <1453889401-43496-1-git-send-email-borntraeger@de.ibm.com> <1453889401-43496-3-git-send-email-borntraeger@de.ibm.com> <56A9E3D1.3090001@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 , davej@codemonkey.org.uk From: Christian Borntraeger Message-ID: <56B12560.4010201@de.ibm.com> Date: Tue, 2 Feb 2016 22:53:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16020221-0033-0000-0000-00000597C22C Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/02/2016 10:51 PM, David Rientjes wrote: > On Thu, 28 Jan 2016, David Rientjes wrote: > >> 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. >> > > Ping? > https://lkml.org/lkml/2016/1/29/266 ? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Borntraeger Subject: Re: [PATCH v3 2/3] x86: query dynamic DEBUG_PAGEALLOC setting Date: Tue, 2 Feb 2016 22:53:36 +0100 Message-ID: <56B12560.4010201@de.ibm.com> References: <1453889401-43496-1-git-send-email-borntraeger@de.ibm.com> <1453889401-43496-3-git-send-email-borntraeger@de.ibm.com> <56A9E3D1.3090001@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: owner-linux-mm@kvack.org List-Archive: List-Post: To: David Rientjes 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 , davej@codemonkey.org.uk List-ID: On 02/02/2016 10:51 PM, David Rientjes wrote: > On Thu, 28 Jan 2016, David Rientjes wrote: > >> 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. >> > > Ping? > https://lkml.org/lkml/2016/1/29/266 ? -- 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: email@kvack.org