Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932070AbbEZMaW (ORCPT ); Tue, 26 May 2015 08:30:22 -0400 Received: from [209.85.192.169] ([209.85.192.169]:33680 "EHLO mail-pd0-f169.google.com" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1753302AbbEZMaS convert rfc822-to-8bit (ORCPT ); Tue, 26 May 2015 08:30:18 -0400 Subject: Re: [RFC PATCH 2/2] arm64: Implement vmalloc based thread_info allocator Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Jungseok Lee In-Reply-To: Date: Tue, 26 May 2015 21:21:02 +0900 Cc: linux-arm-kernel@lists.infradead.org, barami97@gmail.com, Catalin Marinas , Will Deacon , Linux Kernel Mailing List , linux-mm@kvack.org Content-Transfer-Encoding: 8BIT Message-Id: <55C5D0FE-5431-4BFD-B39E-BC75E17D6475@gmail.com> References: <1432483340-23157-1-git-send-email-jungseoklee85@gmail.com> To: yalin wang X-Mailer: Apple Mail (2.1283) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3705 Lines: 85 On May 26, 2015, at 11:52 AM, yalin wang wrote: > 2015-05-25 0:02 GMT+08:00 Jungseok Lee : >> Fork-routine sometimes fails to get a physically contiguous region for >> thread_info on 4KB page system although free memory is enough. That is, >> a physically contiguous region, which is currently 16KB, is not available >> since system memory is fragmented. >> >> This patch tries to solve the problem as allocating thread_info memory >> from vmalloc space, not 1:1 mapping one. The downside is one additional >> page allocation in case of vmalloc. However, vmalloc space is large enough, >> around 240GB, under a combination of 39-bit VA and 4KB page. Thus, it is >> not a big tradeoff for fork-routine service. >> >> Suggested-by: Sungjinn Chung >> Signed-off-by: Jungseok Lee >> Cc: Catalin Marinas >> Cc: Will Deacon >> Cc: linux-kernel@vger.kernel.org >> Cc: linux-mm@kvack.org >> --- >> arch/arm64/Kconfig | 12 ++++++++++++ >> arch/arm64/include/asm/thread_info.h | 9 +++++++++ >> arch/arm64/kernel/process.c | 7 +++++++ >> 3 files changed, 28 insertions(+) >> >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index 99930cf..93c236a 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -536,6 +536,18 @@ config ARCH_SELECT_MEMORY_MODEL >> config HAVE_ARCH_PFN_VALID >> def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM >> >> +config ARCH_THREAD_INFO_ALLOCATOR >> + bool "Enable vmalloc based thread_info allocator (EXPERIMENTAL)" >> + depends on ARM64_4K_PAGES >> + default n >> + help >> + This feature enables vmalloc based thread_info allocator. It >> + prevents fork-routine from begin failed to obtain physically >> + contiguour region due to memory fragmentation on low system >> + memory platforms. >> + >> + If unsure, say N >> + >> config HW_PERF_EVENTS >> bool "Enable hardware performance counter support for perf events" >> depends on PERF_EVENTS >> diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h >> index dcd06d1..e753e59 100644 >> --- a/arch/arm64/include/asm/thread_info.h >> +++ b/arch/arm64/include/asm/thread_info.h >> @@ -61,6 +61,15 @@ struct thread_info { >> #define init_thread_info (init_thread_union.thread_info) >> #define init_stack (init_thread_union.stack) >> >> +#ifdef CONFIG_ARCH_THREAD_INFO_ALLOCATOR >> +#define alloc_thread_info_node(tsk, node) \ >> +({ \ >> + __vmalloc_node_range(THREAD_SIZE, THREAD_SIZE, VMALLOC_START, \ >> + VMALLOC_END, GFP_KERNEL, PAGE_KERNEL, 0, \ >> + NUMA_NO_NODE, __builtin_return_address(0)); \ >> +}) > why not add __GFP_HIGHMEM, if you decided to use vmalloc() alloc stack pages? I do not add the flag since there is no high memory on a current ARM64 kernel. It would be helpful to review include/linux/gfp.h and the following code snippet from arch/arm64/kernel/module.c. void *module_alloc(unsigned long size) { return __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END, GFP_KERNEL, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE, __builtin_return_address(0)); } Best Regards Jungseok Lee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/