Message ID | 1372467663-31425-1-git-send-email-santosh.shilimkar@ti.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Hello, I haven't looked at bootmem for a while so could be a bit out of touch but a couple questions. On Fri, Jun 28, 2013 at 09:01:03PM -0400, Santosh Shilimkar wrote: > - Started replacing bootmem_* usage with dirty hacked memblock based API. > This can be letter wrapped with only needed parameter export. You can't use memblock directly? > - Couple of ARM related patch-ups were fine but soon realized that we need > to patch generic kernel multiple places .. So decided to stop and check again > These changes are becoming too much... I suppose LPAE on arm is analogous to PAE on x86, IOW, high memory? This does affect memory initilization as you need to register memory areas which aren't addressable directly; however, why does it affect generic code which is just allocating memory? Note that x86 already does highmem and the existing code works fine. Once all bootmem users are gone, we can remove the bootmem wrappers but I don't what the point is with introducing yet another wrapper. Thanks.
On Sat, Jun 29, 2013 at 08:29:59AM -0700, Tejun Heo wrote: > I suppose LPAE on arm is analogous to PAE on x86, IOW, high memory? > This does affect memory initilization as you need to register memory > areas which aren't addressable directly; however, why does it affect > generic code which is just allocating memory? Note that x86 already > does highmem and the existing code works fine. Once all bootmem users > are gone, we can remove the bootmem wrappers but I don't what the > point is with introducing yet another wrapper. The reason is actually quite simple: on x86 you always have memory starting at physical address zero. Unfortunately, that has not been true on ARM - it's very common for there to be an offset on physical memory, sometimes of the order of 3GB or more. This is because on reset, ARMs start executing the code at physical address zero, which therefore can't be RAM - and there's a desire to avoid complex switching games in hardware to temporarily map ROM there instead of RAM. On these SoCs which Santosh is working on, the main physical memory mapping is above 4GB, with just a small alias below 4GB to allow the system to boot without the MMU being on, as they may have more than 4GB of RAM. As I understand it, the small alias below 4GB is not suitable for use as a "lowmem" mapping.
( Expanding cc list, original thread is at http://thread.gmane.org/gmane.linux.kernel/1518046 ) Hello, On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote: > Unfortunately, that has not been true on ARM - it's very common for > there to be an offset on physical memory, sometimes of the order of > 3GB or more. This is because on reset, ARMs start executing the code > at physical address zero, which therefore can't be RAM - and there's > a desire to avoid complex switching games in hardware to temporarily > map ROM there instead of RAM. > > On these SoCs which Santosh is working on, the main physical memory > mapping is above 4GB, with just a small alias below 4GB to allow the > system to boot without the MMU being on, as they may have more than > 4GB of RAM. As I understand it, the small alias below 4GB is not > suitable for use as a "lowmem" mapping. Ah, okay, so the @limit which is in physical address can be over 4GB even for lowmem mappings and alloc_bootmem takes them in ulongs, urghhh.... Given that still about half of the archs aren't using memblock yet, I think there are three options. 1. Converting all bootmem interface to use physaddr_t. But that's what memblock is. 2. Introducing new interface. Easier right now but the danger there is that it might end up duplicating most of alloc_bootmem() interface anyway and we'll have yet another variant of early mem allocator to enjoy. 3. Make all generic code use memblock interface instead of bootmem and implement memblock wrapper on archs which don't use memblock yet. We'll probably need to sort out different combinations of HAVE_MEMBLOCK and NO_BOOTMEM. If this is doable, it probably is the most future proof way. While it adds new memblock interface built on top of bootmem, it would also allow removing the bootmem interface built on top of memblock - ie. nobootmem.c, which probably is what we should have done from the beginning. What do you guys think? Thanks.
3 makes sense to me. Tejun Heo <tj@kernel.org> wrote: >( Expanding cc list, original thread is at > http://thread.gmane.org/gmane.linux.kernel/1518046 ) > >Hello, > >On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux >wrote: >> Unfortunately, that has not been true on ARM - it's very common for >> there to be an offset on physical memory, sometimes of the order of >> 3GB or more. This is because on reset, ARMs start executing the code >> at physical address zero, which therefore can't be RAM - and there's >> a desire to avoid complex switching games in hardware to temporarily >> map ROM there instead of RAM. >> >> On these SoCs which Santosh is working on, the main physical memory >> mapping is above 4GB, with just a small alias below 4GB to allow the >> system to boot without the MMU being on, as they may have more than >> 4GB of RAM. As I understand it, the small alias below 4GB is not >> suitable for use as a "lowmem" mapping. > >Ah, okay, so the @limit which is in physical address can be over 4GB >even for lowmem mappings and alloc_bootmem takes them in ulongs, >urghhh.... > >Given that still about half of the archs aren't using memblock yet, I >think there are three options. > >1. Converting all bootmem interface to use physaddr_t. But that's > what memblock is. > >2. Introducing new interface. Easier right now but the danger there > is that it might end up duplicating most of alloc_bootmem() > interface anyway and we'll have yet another variant of early mem > allocator to enjoy. > >3. Make all generic code use memblock interface instead of bootmem and > implement memblock wrapper on archs which don't use memblock yet. > We'll probably need to sort out different combinations of > HAVE_MEMBLOCK and NO_BOOTMEM. If this is doable, it probably is > the most future proof way. While it adds new memblock interface > built on top of bootmem, it would also allow removing the bootmem > interface built on top of memblock - ie. nobootmem.c, which > probably is what we should have done from the beginning. > >What do you guys think? > >Thanks.
On Sat, Jun 29, 2013 at 10:57 AM, Tejun Heo <tj@kernel.org> wrote: > ( Expanding cc list, original thread is at > http://thread.gmane.org/gmane.linux.kernel/1518046 ) > > Hello, > > On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote: >> Unfortunately, that has not been true on ARM - it's very common for >> there to be an offset on physical memory, sometimes of the order of >> 3GB or more. This is because on reset, ARMs start executing the code >> at physical address zero, which therefore can't be RAM - and there's >> a desire to avoid complex switching games in hardware to temporarily >> map ROM there instead of RAM. >> >> On these SoCs which Santosh is working on, the main physical memory >> mapping is above 4GB, with just a small alias below 4GB to allow the >> system to boot without the MMU being on, as they may have more than >> 4GB of RAM. As I understand it, the small alias below 4GB is not >> suitable for use as a "lowmem" mapping. is that 32bit ARM or 64bit ARM? > > Ah, okay, so the @limit which is in physical address can be over 4GB > even for lowmem mappings and alloc_bootmem takes them in ulongs, > urghhh.... > > Given that still about half of the archs aren't using memblock yet, I > think there are three options. > > 1. Converting all bootmem interface to use physaddr_t. But that's > what memblock is. > > 2. Introducing new interface. Easier right now but the danger there > is that it might end up duplicating most of alloc_bootmem() > interface anyway and we'll have yet another variant of early mem > allocator to enjoy. > > 3. Make all generic code use memblock interface instead of bootmem and > implement memblock wrapper on archs which don't use memblock yet. > We'll probably need to sort out different combinations of > HAVE_MEMBLOCK and NO_BOOTMEM. If this is doable, it probably is > the most future proof way. While it adds new memblock interface > built on top of bootmem, it would also allow removing the bootmem > interface built on top of memblock - ie. nobootmem.c, which > probably is what we should have done from the beginning. > > What do you guys think? 2. looks more simple. but will use alloc_memblock as interface. We don't need to use __alloc_memory_core_early() directly, right? Thanks Yinghai
On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote: > On Sat, Jun 29, 2013 at 10:57 AM, Tejun Heo <tj@kernel.org> wrote: > > ( Expanding cc list, original thread is at > > http://thread.gmane.org/gmane.linux.kernel/1518046 ) > > > > Hello, > > > > On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote: > >> Unfortunately, that has not been true on ARM - it's very common for > >> there to be an offset on physical memory, sometimes of the order of > >> 3GB or more. This is because on reset, ARMs start executing the code > >> at physical address zero, which therefore can't be RAM - and there's > >> a desire to avoid complex switching games in hardware to temporarily > >> map ROM there instead of RAM. > >> > >> On these SoCs which Santosh is working on, the main physical memory > >> mapping is above 4GB, with just a small alias below 4GB to allow the > >> system to boot without the MMU being on, as they may have more than > >> 4GB of RAM. As I understand it, the small alias below 4GB is not > >> suitable for use as a "lowmem" mapping. > > is that 32bit ARM or 64bit ARM? Only 32-bit has LPAE. Such things don't make sense on 64-bit CPUs.
On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote: >> >> On these SoCs which Santosh is working on, the main physical memory >> >> mapping is above 4GB, with just a small alias below 4GB to allow the >> >> system to boot without the MMU being on, as they may have more than >> >> 4GB of RAM. As I understand it, the small alias below 4GB is not >> >> suitable for use as a "lowmem" mapping. >> >> is that 32bit ARM or 64bit ARM? > > Only 32-bit has LPAE. Such things don't make sense on 64-bit CPUs. 32bit ARM does not support NO_BOOTMEM yet. arch/arc/Kconfig: select NO_BOOTMEM arch/arm64/Kconfig: select NO_BOOTMEM arch/sparc/Kconfig: select NO_BOOTMEM arch/x86/Kconfig:config NO_BOOTMEM so may need to 1. make 32bit ARM to use NO_BOOTMEM at first. 2 .we can add alloc_memblock as MACRO or inline for bootmem arches, 3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c 4. replace alloc_bootmem calling with alloc_memblock calling in core code. Thanks Yinghai
On Saturday 29 June 2013 04:08 PM, Yinghai Lu wrote: > On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: >> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote: >>>>> On these SoCs which Santosh is working on, the main physical memory >>>>> mapping is above 4GB, with just a small alias below 4GB to allow the >>>>> system to boot without the MMU being on, as they may have more than >>>>> 4GB of RAM. As I understand it, the small alias below 4GB is not >>>>> suitable for use as a "lowmem" mapping. >>> >>> is that 32bit ARM or 64bit ARM? >> >> Only 32-bit has LPAE. Such things don't make sense on 64-bit CPUs. > Thanks Russell for clarifying the issue on the thread. Another major reason of not being to use 32 bit alias address space for lowmem is that address space isn't coherent on the SOC am dealing with. > 32bit ARM does not support NO_BOOTMEM yet. > > arch/arc/Kconfig: select NO_BOOTMEM > arch/arm64/Kconfig: select NO_BOOTMEM > arch/sparc/Kconfig: select NO_BOOTMEM > arch/x86/Kconfig:config NO_BOOTMEM > > > so may need to > 1. make 32bit ARM to use NO_BOOTMEM at first. > Sorry. I should have mentioned that in the change-log. I have been carrying some WIP patches for ARM. Will post them on ARM list after finishing remainder of the testing. > 2 .we can add alloc_memblock as MACRO or inline for bootmem arches, > > 3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c > > 4. replace alloc_bootmem calling with alloc_memblock calling in core code. > Great that we all agree to see back of nobootmem.c and have a direct memblock API. Will be happy to help in conversion to proposed new interfaces if I can get the alloc_memblock API and core related changes. Will be good to know who is going to create proposed memblock API so that we all can collaborate in conversion. Regards, Santosh
Tejun, On Monday 01 July 2013 10:10 AM, Santosh Shilimkar wrote: > On Saturday 29 June 2013 04:08 PM, Yinghai Lu wrote: >> On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux >> <linux@arm.linux.org.uk> wrote: >>> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote: >>>>>> On these SoCs which Santosh is working on, the main physical memory >>>>>> mapping is above 4GB, with just a small alias below 4GB to allow the >>>>>> system to boot without the MMU being on, as they may have more than >>>>>> 4GB of RAM. As I understand it, the small alias below 4GB is not >>>>>> suitable for use as a "lowmem" mapping. >>>> >>>> is that 32bit ARM or 64bit ARM? >>> >>> Only 32-bit has LPAE. Such things don't make sense on 64-bit CPUs. >> > Thanks Russell for clarifying the issue on the thread. Another major > reason of not being to use 32 bit alias address space for lowmem > is that address space isn't coherent on the SOC am dealing with. > >> 32bit ARM does not support NO_BOOTMEM yet. >> >> arch/arc/Kconfig: select NO_BOOTMEM >> arch/arm64/Kconfig: select NO_BOOTMEM >> arch/sparc/Kconfig: select NO_BOOTMEM >> arch/x86/Kconfig:config NO_BOOTMEM >> >> >> so may need to >> 1. make 32bit ARM to use NO_BOOTMEM at first. >> > Sorry. I should have mentioned that in the change-log. > I have been carrying some WIP patches for ARM. Will post them > on ARM list after finishing remainder of the testing. > >> 2 .we can add alloc_memblock as MACRO or inline for bootmem arches, >> >> 3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c >> >> 4. replace alloc_bootmem calling with alloc_memblock calling in core code. >> > Great that we all agree to see back of nobootmem.c and have a direct > memblock API. Will be happy to help in conversion to proposed new interfaces > if I can get the alloc_memblock API and core related changes. > > Will be good to know who is going to create proposed memblock API > so that we all can collaborate in conversion. > Any comments here. I would like to know your plan for the new API. You might have seen on the ARM no-bootmem thread, we started to move ARM to nobootmem with Russell's help. Regards, Santosh
Hello, On Thu, Jul 25, 2013 at 06:33:14PM -0400, Santosh Shilimkar wrote: > Any comments here. I would like to know your plan for the new > API. You might have seen on the ARM no-bootmem thread, we started to > move ARM to nobootmem with Russell's help. Ooh, the plan sounds good to me and I was thinking you were gonna do it? Thanks.
On Thursday 25 July 2013 06:36 PM, Tejun Heo wrote: > Hello, > > On Thu, Jul 25, 2013 at 06:33:14PM -0400, Santosh Shilimkar wrote: >> Any comments here. I would like to know your plan for the new >> API. You might have seen on the ARM no-bootmem thread, we started to >> move ARM to nobootmem with Russell's help. > > Ooh, the plan sounds good to me and I was thinking you were gonna do > it? > Wooo.. Sorry if I wasn't clear before, but I need help to at least have new memblock API support since I am not familiar with memblock code. I could help in adaptation to the new API for ARM arch and core kernel code. Let me know your thoughts. Regards, Santosh
Hello, On Thu, Jul 25, 2013 at 07:15:11PM -0400, Santosh Shilimkar wrote: > Sorry if I wasn't clear before, but I need help to at least have new > memblock API support since I am not familiar with memblock code. > I could help in adaptation to the new API for ARM arch and > core kernel code. > > Let me know your thoughts. Unfortunately, I'm currently a bit too occupied to work on it myself. Any volunteers? Thanks.
Tejun, On Thursday 25 July 2013 11:08 PM, Tejun Heo wrote: > Hello, > > On Thu, Jul 25, 2013 at 07:15:11PM -0400, Santosh Shilimkar wrote: >> Sorry if I wasn't clear before, but I need help to at least have new >> memblock API support since I am not familiar with memblock code. >> I could help in adaptation to the new API for ARM arch and >> core kernel code. >> >> Let me know your thoughts. > > Unfortunately, I'm currently a bit too occupied to work on it myself. > Any volunteers? > Looking at the situation, how about proceeding with patch updating the bootmem API signatures to use phys_addr_t which can unblock me to get my machine working. Introduction of new API, conversions of core kernel code and then arches moving away from bootmem is going to take significant time anyways. I will continue my effort to get ARM port moved to no-bootmem and get that merged. Let me know how to make progress here. Appreciate your help on the subject. Regards, Santosh
Hello, On Fri, Aug 02, 2013 at 05:06:02PM -0400, Santosh Shilimkar wrote: > Looking at the situation, how about proceeding with patch updating > the bootmem API signatures to use phys_addr_t which can unblock me > to get my machine working. I'm not sure about that. No matter how you play it, it'll end up duplicating memblock interface. > Introduction of new API, conversions of core kernel code and then What new API are we talking about? Wasn't the plan to convert core kernel code to use memblock and let bootmem emulate bootmem API? There's no new API. > arches moving away from bootmem is going to take significant time And arches moving away from bootmem doesn't have to happen now. > anyways. I will continue my effort to get ARM port moved to no-bootmem > and get that merged. Thanks.
On Monday 05 August 2013 11:01 AM, Tejun Heo wrote: > Hello, > > On Fri, Aug 02, 2013 at 05:06:02PM -0400, Santosh Shilimkar wrote: >> Looking at the situation, how about proceeding with patch updating >> the bootmem API signatures to use phys_addr_t which can unblock me >> to get my machine working. > > I'm not sure about that. No matter how you play it, it'll end up > duplicating memblock interface. > fair enough. >> Introduction of new API, conversions of core kernel code and then > > What new API are we talking about? Wasn't the plan to convert core > kernel code to use memblock and let bootmem emulate bootmem API? > There's no new API. > So looks like I am bit confused here. The current memblock_alloc() API just returns the physical address which not mapped memory. Most of the bootmem users including core code expects the mapped memory pointer which the code can directly operate on. So the current memblock_alloc() isn't going to help. The nobootmem.c has __alloc_memory_core_early() which is actually used by most of the bootmem wrappers to achieve the same. So my assumption was that we need an equivalent exported memblock API. What am I missing? >> arches moving away from bootmem is going to take significant time > > And arches moving away from bootmem doesn't have to happen now. > I agree. The core code conversion is more of an issue. Regards, Santosh
Hello, On Mon, Aug 05, 2013 at 11:29:46AM -0400, Santosh Shilimkar wrote: > So looks like I am bit confused here. The current memblock_alloc() > API just returns the physical address which not mapped memory. The memory returned by memblock is mapped if the memory area being allocated can be mappable. To access, the address just needs to be converted to va. > Most of the bootmem users including core code expects the > mapped memory pointer which the code can directly operate on. > So the current memblock_alloc() isn't going to help. The nobootmem.c > has __alloc_memory_core_early() which is actually used by most of > the bootmem wrappers to achieve the same. So my assumption was > that we need an equivalent exported memblock API. > > What am I missing? Oh, you weren't. I was. I thought we already had full interface implemented. Yeah, it looks like we need to build something new around memblock / __alloc_memory_core_early(). Thanks.
On Monday 05 August 2013 11:38 AM, Tejun Heo wrote: > Hello, > > On Mon, Aug 05, 2013 at 11:29:46AM -0400, Santosh Shilimkar wrote: >> So looks like I am bit confused here. The current memblock_alloc() >> API just returns the physical address which not mapped memory. > > The memory returned by memblock is mapped if the memory area being > allocated can be mappable. To access, the address just needs to be > converted to va. > >> Most of the bootmem users including core code expects the >> mapped memory pointer which the code can directly operate on. >> So the current memblock_alloc() isn't going to help. The nobootmem.c >> has __alloc_memory_core_early() which is actually used by most of >> the bootmem wrappers to achieve the same. So my assumption was >> that we need an equivalent exported memblock API. >> >> What am I missing? > > Oh, you weren't. I was. I thought we already had full interface > implemented. Yeah, it looks like we need to build something new > around memblock / __alloc_memory_core_early(). > Exactly. This is what actually I referred as the new API. Regards, Santosh
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c index 5af04f6..720b9f9 100644 --- a/arch/arm/kernel/devtree.c +++ b/arch/arm/kernel/devtree.c @@ -33,7 +33,7 @@ void __init early_init_dt_add_memory_arch(u64 base, u64 size) void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align) { - return alloc_bootmem_align(size, align); + return __alloc_memory_core_early(MAX_NUMNODES, size, align, 0, ARCH_LOW_ADDRESS_LIMIT); } void __init arm_dt_memblock_reserve(void) diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c index 385131c..57698ed 100644 --- a/arch/arm/kernel/setup.c +++ b/arch/arm/kernel/setup.c @@ -619,7 +619,7 @@ static void __init request_standard_resources(struct machine_desc *mdesc) kernel_data.end = virt_to_phys(_end - 1); for_each_memblock(memory, region) { - res = alloc_bootmem_low(sizeof(*res)); + res = __alloc_memory_core_early(MAX_NUMNODES, sizeof(*res), SMP_CACHE_BYTES, 0, ARCH_LOW_ADDRESS_LIMIT); res->name = "System RAM"; res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region)); res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1; diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h index 5f0b0e1..a916df6 100644 --- a/include/linux/bootmem.h +++ b/include/linux/bootmem.h @@ -142,6 +142,8 @@ extern void *__alloc_bootmem_low_node(pg_data_t *pgdat, #define alloc_bootmem_low_pages_node(pgdat, x) \ __alloc_bootmem_low_node(pgdat, x, PAGE_SIZE, 0) +extern void * __init __alloc_memory_core_early(int nid, u64 size, u64 align, + u64 goal, u64 limit); #ifdef CONFIG_HAVE_ARCH_ALLOC_REMAP extern void *alloc_remap(int nid, unsigned long size); #else diff --git a/init/main.c b/init/main.c index 9484f4b..53c488d 100644 --- a/init/main.c +++ b/init/main.c @@ -344,8 +344,8 @@ static inline void smp_prepare_cpus(unsigned int maxcpus) { } */ static void __init setup_command_line(char *command_line) { - saved_command_line = alloc_bootmem(strlen (boot_command_line)+1); - static_command_line = alloc_bootmem(strlen (command_line)+1); + saved_command_line =__alloc_memory_core_early(MAX_NUMNODES, (strlen (boot_command_line)+1), SMP_CACHE_BYTES, 0, ARCH_LOW_ADDRESS_LIMIT); + static_command_line =__alloc_memory_core_early(MAX_NUMNODES, (strlen (command_line)+1), SMP_CACHE_BYTES, 0, ARCH_LOW_ADDRESS_LIMIT); strcpy (saved_command_line, boot_command_line); strcpy (static_command_line, command_line); } diff --git a/mm/nobootmem.c b/mm/nobootmem.c index bdd3fa2..43a2f95 100644 --- a/mm/nobootmem.c +++ b/mm/nobootmem.c @@ -32,7 +32,7 @@ unsigned long max_low_pfn; unsigned long min_low_pfn; unsigned long max_pfn; -static void * __init __alloc_memory_core_early(int nid, u64 size, u64 align, +void * __init __alloc_memory_core_early(int nid, u64 size, u64 align, u64 goal, u64 limit) { void *ptr; diff --git a/mm/percpu.c b/mm/percpu.c index 8c8e08f..30cd3df 100644 --- a/mm/percpu.c +++ b/mm/percpu.c @@ -1063,7 +1063,7 @@ struct pcpu_alloc_info * __init pcpu_alloc_alloc_info(int nr_groups, __alignof__(ai->groups[0].cpu_map[0])); ai_size = base_size + nr_units * sizeof(ai->groups[0].cpu_map[0]); - ptr = alloc_bootmem_nopanic(PFN_ALIGN(ai_size)); + ptr = __alloc_memory_core_early(MAX_NUMNODES, PFN_ALIGN(ai_size), SMP_CACHE_BYTES, 0, ARCH_LOW_ADDRESS_LIMIT); if (!ptr) return NULL; ai = ptr; @@ -1895,7 +1895,7 @@ void __init setup_per_cpu_areas(void) void *fc; ai = pcpu_alloc_alloc_info(1, 1); - fc = __alloc_bootmem(unit_size, PAGE_SIZE, __pa(MAX_DMA_ADDRESS)); + fc = __alloc_memory_core_early(MAX_NUMNODES, unit_size, PAGE_SIZE, __pa(MAX_DMA_ADDRESS), ARCH_LOW_ADDRESS_LIMIT); if (!ai || !fc) panic("Failed to allocate memory for percpu areas."); /* kmemleak tracks the percpu allocations separately */