Re: [PATCH] mm: bootmem: use phys_addr_t for physical addresses
Hello, Cyril. On Wed, Sep 12, 2012 at 08:40:58PM -0400, Cyril Chemparathy wrote: > You probably missed the lowmem bit from my response? > > This system has all of its memory outside the 4GB physical address > space. This includes lowmem, which is permanently mapped into the > kernel virtual address space as usual. Yeah, I understand that and as a short-term solution we maybe can add a check to verify that the goal and limits are under lowmem and fail with NULL if not, but it still is a broken interface and I'd rather not mess with it when memblock is already there. Converting to memblock usually isn't too much work although it expectedly involves some subtleties and fallouts for a while. Do you recall what the problem was with sparsemem and memblock? I don't think I'll directly work on arm but I'll be happy to help on memblock issues. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: bootmem: use phys_addr_t for physical addresses
Hello, Cyril. On Wed, Sep 12, 2012 at 08:40:58PM -0400, Cyril Chemparathy wrote: You probably missed the lowmem bit from my response? This system has all of its memory outside the 4GB physical address space. This includes lowmem, which is permanently mapped into the kernel virtual address space as usual. Yeah, I understand that and as a short-term solution we maybe can add a check to verify that the goal and limits are under lowmem and fail with NULL if not, but it still is a broken interface and I'd rather not mess with it when memblock is already there. Converting to memblock usually isn't too much work although it expectedly involves some subtleties and fallouts for a while. Do you recall what the problem was with sparsemem and memblock? I don't think I'll directly work on arm but I'll be happy to help on memblock issues. Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: bootmem: use phys_addr_t for physical addresses
Hi Tejun, On 9/12/2012 8:34 PM, Tejun Heo wrote: Hello, On Wed, Sep 12, 2012 at 08:08:30PM -0400, Cyril Chemparathy wrote: So, a function which takes phys_addr_t for goal and limit but returns void * doesn't make much sense unless the function creates directly addressable mapping somewhere. On the 32-bit PAE platform in question, physical memory is located outside the 4GB range. Therefore phys_to_virt takes a 64-bit physical address and returns a 32-bit kernel mapped lowmem pointer. Yes but phys_to_virt() can return the vaddr only if the physical address is already mapped in the kernel address space; otherwise, you need one of the kmap*() calls which may not be online early in the boot and consumes either the vmalloc area or fixmaps. bootmem interface can't handle unmapped memory. You probably missed the lowmem bit from my response? This system has all of its memory outside the 4GB physical address space. This includes lowmem, which is permanently mapped into the kernel virtual address space as usual. -- Thanks - Cyril -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: bootmem: use phys_addr_t for physical addresses
Hello, On Wed, Sep 12, 2012 at 08:08:30PM -0400, Cyril Chemparathy wrote: > >So, a function which takes phys_addr_t for goal and limit but returns > >void * doesn't make much sense unless the function creates directly > >addressable mapping somewhere. > > On the 32-bit PAE platform in question, physical memory is located > outside the 4GB range. Therefore phys_to_virt takes a 64-bit > physical address and returns a 32-bit kernel mapped lowmem pointer. Yes but phys_to_virt() can return the vaddr only if the physical address is already mapped in the kernel address space; otherwise, you need one of the kmap*() calls which may not be online early in the boot and consumes either the vmalloc area or fixmaps. bootmem interface can't handle unmapped memory. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: bootmem: use phys_addr_t for physical addresses
Hi Tejun, On 9/12/2012 4:39 PM, Tejun Heo wrote: Hello, On Wed, Sep 12, 2012 at 12:06:48PM -0400, Cyril Chemparathy wrote: static void * __init alloc_bootmem_core(unsigned long size, unsigned long align, - unsigned long goal, - unsigned long limit) + phys_addr_t goal, + phys_addr_t limit) So, a function which takes phys_addr_t for goal and limit but returns void * doesn't make much sense unless the function creates directly addressable mapping somewhere. On the 32-bit PAE platform in question, physical memory is located outside the 4GB range. Therefore phys_to_virt takes a 64-bit physical address and returns a 32-bit kernel mapped lowmem pointer. The right thing to do would be converting to nobootmem (ie. memblock) and use the memblock interface. Have no idea at all whether that would be a realistic short-term solution for arm. I must plead ignorance and let wiser souls chime in on ARM architecture plans w.r.t. nobootmem. As far as I can tell, the only thing that blocks us from using nobootmem at present is the need for sparsemem on some platforms. -- Thanks - Cyril -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: bootmem: use phys_addr_t for physical addresses
Hello, On Wed, Sep 12, 2012 at 12:06:48PM -0400, Cyril Chemparathy wrote: > static void * __init alloc_bootmem_core(unsigned long size, > unsigned long align, > - unsigned long goal, > - unsigned long limit) > + phys_addr_t goal, > + phys_addr_t limit) So, a function which takes phys_addr_t for goal and limit but returns void * doesn't make much sense unless the function creates directly addressable mapping somewhere. The right thing to do would be converting to nobootmem (ie. memblock) and use the memblock interface. Have no idea at all whether that would be a realistic short-term solution for arm. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: bootmem: use phys_addr_t for physical addresses
From: Vitaly Andrianov On a physical address extended (PAE) systems physical memory may be located outside the first 4GB address range. In particular, on TI Keystone devices, all memory (including lowmem) is located outside the 4G address space. Many functions in the bootmem.c use unsigned long as a type for physical addresses, and this breaks badly on such PAE systems. This patch intensively mangles the bootmem allocator to use phys_addr_t where necessary. We are aware that this is most certainly not the way to go considering that the ARM architecture appears to be moving towards memblock. Memblock may be a better solution, and fortunately it looks a lot more PAE savvy than bootmem is. However, we do not fully understand the motivations and restrictions behind the mixed bootmem + memblock model in current ARM code. We hope for a meaningful discussion and useful guidance towards a better solution to this problem. Signed-off-by: Vitaly Andrianov Signed-off-by: Cyril Chemparathy --- include/linux/bootmem.h | 30 mm/bootmem.c| 59 --- 2 files changed, 45 insertions(+), 44 deletions(-) diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h index 6d6795d..e43c463 100644 --- a/include/linux/bootmem.h +++ b/include/linux/bootmem.h @@ -49,10 +49,10 @@ extern unsigned long free_all_bootmem_node(pg_data_t *pgdat); extern unsigned long free_all_bootmem(void); extern void free_bootmem_node(pg_data_t *pgdat, - unsigned long addr, + phys_addr_t addr, unsigned long size); -extern void free_bootmem(unsigned long addr, unsigned long size); -extern void free_bootmem_late(unsigned long addr, unsigned long size); +extern void free_bootmem(phys_addr_t addr, unsigned long size); +extern void free_bootmem_late(phys_addr_t addr, unsigned long size); /* * Flags for reserve_bootmem (also if CONFIG_HAVE_ARCH_BOOTMEM_NODE, @@ -65,44 +65,44 @@ extern void free_bootmem_late(unsigned long addr, unsigned long size); #define BOOTMEM_DEFAULT0 #define BOOTMEM_EXCLUSIVE (1<<0) -extern int reserve_bootmem(unsigned long addr, +extern int reserve_bootmem(phys_addr_t addr, unsigned long size, int flags); extern int reserve_bootmem_node(pg_data_t *pgdat, - unsigned long physaddr, + phys_addr_t physaddr, unsigned long size, int flags); extern void *__alloc_bootmem(unsigned long size, unsigned long align, -unsigned long goal); +phys_addr_t goal); extern void *__alloc_bootmem_nopanic(unsigned long size, unsigned long align, -unsigned long goal); +phys_addr_t goal); extern void *__alloc_bootmem_node(pg_data_t *pgdat, unsigned long size, unsigned long align, - unsigned long goal); + phys_addr_t goal); void *__alloc_bootmem_node_high(pg_data_t *pgdat, unsigned long size, unsigned long align, - unsigned long goal); + phys_addr_t goal); extern void *__alloc_bootmem_node_nopanic(pg_data_t *pgdat, unsigned long size, unsigned long align, - unsigned long goal); + phys_addr_t goal); void *___alloc_bootmem_node_nopanic(pg_data_t *pgdat, unsigned long size, unsigned long align, - unsigned long goal, - unsigned long limit); + phys_addr_t goal, + phys_addr_t limit); extern void *__alloc_bootmem_low(unsigned long size, unsigned long align, -unsigned long goal); +phys_addr_t goal); extern void *__alloc_bootmem_low_node(pg_data_t *pgdat, unsigned long size, unsigned long align, - unsigned long goal); + phys_addr_t goal); #ifdef CONFIG_NO_BOOTMEM /* We are using top down, so it is safe to use 0 here */ @@ -137,7 +137,7 @@ extern void *__alloc_bootmem_low_node(pg_data_t *pgdat, #define alloc_bootmem_low_pages_node(pgdat, x) \
[PATCH] mm: bootmem: use phys_addr_t for physical addresses
From: Vitaly Andrianov vita...@ti.com On a physical address extended (PAE) systems physical memory may be located outside the first 4GB address range. In particular, on TI Keystone devices, all memory (including lowmem) is located outside the 4G address space. Many functions in the bootmem.c use unsigned long as a type for physical addresses, and this breaks badly on such PAE systems. This patch intensively mangles the bootmem allocator to use phys_addr_t where necessary. We are aware that this is most certainly not the way to go considering that the ARM architecture appears to be moving towards memblock. Memblock may be a better solution, and fortunately it looks a lot more PAE savvy than bootmem is. However, we do not fully understand the motivations and restrictions behind the mixed bootmem + memblock model in current ARM code. We hope for a meaningful discussion and useful guidance towards a better solution to this problem. Signed-off-by: Vitaly Andrianov vita...@ti.com Signed-off-by: Cyril Chemparathy cy...@ti.com --- include/linux/bootmem.h | 30 mm/bootmem.c| 59 --- 2 files changed, 45 insertions(+), 44 deletions(-) diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h index 6d6795d..e43c463 100644 --- a/include/linux/bootmem.h +++ b/include/linux/bootmem.h @@ -49,10 +49,10 @@ extern unsigned long free_all_bootmem_node(pg_data_t *pgdat); extern unsigned long free_all_bootmem(void); extern void free_bootmem_node(pg_data_t *pgdat, - unsigned long addr, + phys_addr_t addr, unsigned long size); -extern void free_bootmem(unsigned long addr, unsigned long size); -extern void free_bootmem_late(unsigned long addr, unsigned long size); +extern void free_bootmem(phys_addr_t addr, unsigned long size); +extern void free_bootmem_late(phys_addr_t addr, unsigned long size); /* * Flags for reserve_bootmem (also if CONFIG_HAVE_ARCH_BOOTMEM_NODE, @@ -65,44 +65,44 @@ extern void free_bootmem_late(unsigned long addr, unsigned long size); #define BOOTMEM_DEFAULT0 #define BOOTMEM_EXCLUSIVE (10) -extern int reserve_bootmem(unsigned long addr, +extern int reserve_bootmem(phys_addr_t addr, unsigned long size, int flags); extern int reserve_bootmem_node(pg_data_t *pgdat, - unsigned long physaddr, + phys_addr_t physaddr, unsigned long size, int flags); extern void *__alloc_bootmem(unsigned long size, unsigned long align, -unsigned long goal); +phys_addr_t goal); extern void *__alloc_bootmem_nopanic(unsigned long size, unsigned long align, -unsigned long goal); +phys_addr_t goal); extern void *__alloc_bootmem_node(pg_data_t *pgdat, unsigned long size, unsigned long align, - unsigned long goal); + phys_addr_t goal); void *__alloc_bootmem_node_high(pg_data_t *pgdat, unsigned long size, unsigned long align, - unsigned long goal); + phys_addr_t goal); extern void *__alloc_bootmem_node_nopanic(pg_data_t *pgdat, unsigned long size, unsigned long align, - unsigned long goal); + phys_addr_t goal); void *___alloc_bootmem_node_nopanic(pg_data_t *pgdat, unsigned long size, unsigned long align, - unsigned long goal, - unsigned long limit); + phys_addr_t goal, + phys_addr_t limit); extern void *__alloc_bootmem_low(unsigned long size, unsigned long align, -unsigned long goal); +phys_addr_t goal); extern void *__alloc_bootmem_low_node(pg_data_t *pgdat, unsigned long size, unsigned long align, - unsigned long goal); + phys_addr_t goal); #ifdef CONFIG_NO_BOOTMEM /* We are using top down, so it is safe to use 0 here */ @@ -137,7 +137,7 @@ extern void *__alloc_bootmem_low_node(pg_data_t *pgdat, #define
Re: [PATCH] mm: bootmem: use phys_addr_t for physical addresses
Hello, On Wed, Sep 12, 2012 at 12:06:48PM -0400, Cyril Chemparathy wrote: static void * __init alloc_bootmem_core(unsigned long size, unsigned long align, - unsigned long goal, - unsigned long limit) + phys_addr_t goal, + phys_addr_t limit) So, a function which takes phys_addr_t for goal and limit but returns void * doesn't make much sense unless the function creates directly addressable mapping somewhere. The right thing to do would be converting to nobootmem (ie. memblock) and use the memblock interface. Have no idea at all whether that would be a realistic short-term solution for arm. Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: bootmem: use phys_addr_t for physical addresses
Hi Tejun, On 9/12/2012 4:39 PM, Tejun Heo wrote: Hello, On Wed, Sep 12, 2012 at 12:06:48PM -0400, Cyril Chemparathy wrote: static void * __init alloc_bootmem_core(unsigned long size, unsigned long align, - unsigned long goal, - unsigned long limit) + phys_addr_t goal, + phys_addr_t limit) So, a function which takes phys_addr_t for goal and limit but returns void * doesn't make much sense unless the function creates directly addressable mapping somewhere. On the 32-bit PAE platform in question, physical memory is located outside the 4GB range. Therefore phys_to_virt takes a 64-bit physical address and returns a 32-bit kernel mapped lowmem pointer. The right thing to do would be converting to nobootmem (ie. memblock) and use the memblock interface. Have no idea at all whether that would be a realistic short-term solution for arm. I must plead ignorance and let wiser souls chime in on ARM architecture plans w.r.t. nobootmem. As far as I can tell, the only thing that blocks us from using nobootmem at present is the need for sparsemem on some platforms. -- Thanks - Cyril -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: bootmem: use phys_addr_t for physical addresses
Hello, On Wed, Sep 12, 2012 at 08:08:30PM -0400, Cyril Chemparathy wrote: So, a function which takes phys_addr_t for goal and limit but returns void * doesn't make much sense unless the function creates directly addressable mapping somewhere. On the 32-bit PAE platform in question, physical memory is located outside the 4GB range. Therefore phys_to_virt takes a 64-bit physical address and returns a 32-bit kernel mapped lowmem pointer. Yes but phys_to_virt() can return the vaddr only if the physical address is already mapped in the kernel address space; otherwise, you need one of the kmap*() calls which may not be online early in the boot and consumes either the vmalloc area or fixmaps. bootmem interface can't handle unmapped memory. Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: bootmem: use phys_addr_t for physical addresses
Hi Tejun, On 9/12/2012 8:34 PM, Tejun Heo wrote: Hello, On Wed, Sep 12, 2012 at 08:08:30PM -0400, Cyril Chemparathy wrote: So, a function which takes phys_addr_t for goal and limit but returns void * doesn't make much sense unless the function creates directly addressable mapping somewhere. On the 32-bit PAE platform in question, physical memory is located outside the 4GB range. Therefore phys_to_virt takes a 64-bit physical address and returns a 32-bit kernel mapped lowmem pointer. Yes but phys_to_virt() can return the vaddr only if the physical address is already mapped in the kernel address space; otherwise, you need one of the kmap*() calls which may not be online early in the boot and consumes either the vmalloc area or fixmaps. bootmem interface can't handle unmapped memory. You probably missed the lowmem bit from my response? This system has all of its memory outside the 4GB physical address space. This includes lowmem, which is permanently mapped into the kernel virtual address space as usual. -- Thanks - Cyril -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
