[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1453884618-33852-1-git-send-email-borntraeger@de.ibm.com>
Date: Wed, 27 Jan 2016 09:50:15 +0100
From: Christian Borntraeger <borntraeger@...ibm.com>
To: linux-kernel@...r.kernel.org
Cc: akpm@...ux-foundation.org, linux-mm@...ck.org,
linux-arch@...r.kernel.org, linux-s390@...r.kernel.org,
x86@...nel.org, linuxppc-dev@...ts.ozlabs.org, davem@...emloft.net,
Joonsoo Kim <iamjoonsoo.kim@....com>, davej@...emonkey.org.uk,
Christian Borntraeger <borntraeger@...ibm.com>
Subject: [PATCH v2 0/3] Optimize CONFIG_DEBUG_PAGEALLOC
As CONFIG_DEBUG_PAGEALLOC can be enabled/disabled via kernel
parameters we can optimize some cases by checking the enablement
state.
I have done s390 and x86 as examples.
s390 should be ok, I tested several combinations, x86 seems to
work as well, but I have some concerns about the 1GB pages.
The previous code did not bother at all with CONFIG_DEBUG_PAGEALLOC
and I do not fully understand why.
Power can probably do the same, Michael/Ben?
I am not sure about sparc. Sparc seems to allocate the TSB buffer
really early. David?
V1->V2:
- replace DEBUG_PAGEALLOC(disabled/enabled) with DEBUG_PAGEALLOC
dump_stack for s390/x86
- add /* CONFIG_DEBUG_PAGEALLOC */ to else and endif
Christian Borntraeger (3):
mm: provide debug_pagealloc_enabled() without CONFIG_DEBUG_PAGEALLOC
x86: query dynamic DEBUG_PAGEALLOC setting
s390: query dynamic DEBUG_PAGEALLOC setting
arch/s390/kernel/dumpstack.c | 8 ++++----
arch/s390/mm/vmem.c | 10 ++++------
arch/x86/kernel/dumpstack.c | 5 ++---
arch/x86/mm/init.c | 7 ++++---
arch/x86/mm/pageattr.c | 14 ++++----------
include/linux/mm.h | 9 +++++++--
6 files changed, 25 insertions(+), 28 deletions(-)
--
2.3.0
Powered by blists - more mailing lists