Re: [Xen-devel] [PATCH v2 10/21] memblock: refactor internal allocation functions
On Sun, Feb 03, 2019 at 08:39:20PM +1100, Michael Ellerman wrote: > Mike Rapoport writes: > > > Currently, memblock has several internal functions with overlapping > > functionality. They all call memblock_find_in_range_node() to find free > > memory and then reserve the allocated range and mark it with kmemleak. > > However, there is difference in the allocation constraints and in fallback > > strategies. > > > > The allocations returning physical address first attempt to find free > > memory on the specified node within mirrored memory regions, then retry on > > the same node without the requirement for memory mirroring and finally fall > > back to all available memory. > > > > The allocations returning virtual address start with clamping the allowed > > range to memblock.current_limit, attempt to allocate from the specified > > node from regions with mirroring and with user defined minimal address. If > > such allocation fails, next attempt is done with node restriction lifted. > > Next, the allocation is retried with minimal address reset to zero and at > > last without the requirement for mirrored regions. > > > > Let's consolidate various fallbacks handling and make them more consistent > > for physical and virtual variants. Most of the fallback handling is moved > > to memblock_alloc_range_nid() and it now handles node and mirror fallbacks. > > > > The memblock_alloc_internal() uses memblock_alloc_range_nid() to get a > > physical address of the allocated range and converts it to virtual address. > > > > The fallback for allocation below the specified minimal address remains in > > memblock_alloc_internal() because memblock_alloc_range_nid() is used by CMA > > with exact requirement for lower bounds. > > This is causing problems on some of my machines. > > I see NODE_DATA allocations falling back to node 0 when they shouldn't, > or didn't previously. > > eg, before: > > 57990190: (116011251): numa: NODE_DATA [mem 0xfffe4980-0xfffebfff] > 58152042: (116373087): numa: NODE_DATA [mem 0x8fff90980-0x8fff97fff] > > after: > > 16356872061562: (6296877055): numa: NODE_DATA [mem 0xfffe4980-0xfffebfff] > 16356872079279: (6296894772): numa: NODE_DATA [mem 0xfffcd300-0xfffd497f] > 16356872096376: (6296911869): numa: NODE_DATA(1) on node 0 > > > On some of my other systems it does that, and then panics because it > can't allocate anything at all: > > [0.00] numa: NODE_DATA [mem 0x7ffcaee80-0x7ffcb3fff] > [0.00] numa: NODE_DATA [mem 0x7ffc99d00-0x7ffc9ee7f] > [0.00] numa: NODE_DATA(1) on node 0 > [0.00] Kernel panic - not syncing: Cannot allocate 20864 bytes for > node 16 data > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted > 5.0.0-rc4-gccN-next-20190201-gdc4c899 #1 > [0.00] Call Trace: > [0.00] [c11cfca0] [c0c11044] dump_stack+0xe8/0x164 > (unreliable) > [0.00] [c11cfcf0] [c00fdd6c] panic+0x17c/0x3e0 > [0.00] [c11cfd90] [c0f61bc8] initmem_init+0x128/0x260 > [0.00] [c11cfe60] [c0f57940] setup_arch+0x398/0x418 > [0.00] [c11cfee0] [c0f50a94] start_kernel+0xa0/0x684 > [0.00] [c11cff90] [c000af70] > start_here_common+0x1c/0x52c > [0.00] Rebooting in 180 seconds.. > > > So there's something going wrong there, I haven't had time to dig into > it though (Sunday night here). I'll try to see if I can reproduce it with qemu. > cheers > -- Sincerely yours, Mike. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 10/21] memblock: refactor internal allocation functions
Mike Rapoport writes: > Currently, memblock has several internal functions with overlapping > functionality. They all call memblock_find_in_range_node() to find free > memory and then reserve the allocated range and mark it with kmemleak. > However, there is difference in the allocation constraints and in fallback > strategies. > > The allocations returning physical address first attempt to find free > memory on the specified node within mirrored memory regions, then retry on > the same node without the requirement for memory mirroring and finally fall > back to all available memory. > > The allocations returning virtual address start with clamping the allowed > range to memblock.current_limit, attempt to allocate from the specified > node from regions with mirroring and with user defined minimal address. If > such allocation fails, next attempt is done with node restriction lifted. > Next, the allocation is retried with minimal address reset to zero and at > last without the requirement for mirrored regions. > > Let's consolidate various fallbacks handling and make them more consistent > for physical and virtual variants. Most of the fallback handling is moved > to memblock_alloc_range_nid() and it now handles node and mirror fallbacks. > > The memblock_alloc_internal() uses memblock_alloc_range_nid() to get a > physical address of the allocated range and converts it to virtual address. > > The fallback for allocation below the specified minimal address remains in > memblock_alloc_internal() because memblock_alloc_range_nid() is used by CMA > with exact requirement for lower bounds. This is causing problems on some of my machines. I see NODE_DATA allocations falling back to node 0 when they shouldn't, or didn't previously. eg, before: 57990190: (116011251): numa: NODE_DATA [mem 0xfffe4980-0xfffebfff] 58152042: (116373087): numa: NODE_DATA [mem 0x8fff90980-0x8fff97fff] after: 16356872061562: (6296877055): numa: NODE_DATA [mem 0xfffe4980-0xfffebfff] 16356872079279: (6296894772): numa: NODE_DATA [mem 0xfffcd300-0xfffd497f] 16356872096376: (6296911869): numa: NODE_DATA(1) on node 0 On some of my other systems it does that, and then panics because it can't allocate anything at all: [0.00] numa: NODE_DATA [mem 0x7ffcaee80-0x7ffcb3fff] [0.00] numa: NODE_DATA [mem 0x7ffc99d00-0x7ffc9ee7f] [0.00] numa: NODE_DATA(1) on node 0 [0.00] Kernel panic - not syncing: Cannot allocate 20864 bytes for node 16 data [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc4-gccN-next-20190201-gdc4c899 #1 [0.00] Call Trace: [0.00] [c11cfca0] [c0c11044] dump_stack+0xe8/0x164 (unreliable) [0.00] [c11cfcf0] [c00fdd6c] panic+0x17c/0x3e0 [0.00] [c11cfd90] [c0f61bc8] initmem_init+0x128/0x260 [0.00] [c11cfe60] [c0f57940] setup_arch+0x398/0x418 [0.00] [c11cfee0] [c0f50a94] start_kernel+0xa0/0x684 [0.00] [c11cff90] [c000af70] start_here_common+0x1c/0x52c [0.00] Rebooting in 180 seconds.. So there's something going wrong there, I haven't had time to dig into it though (Sunday night here). cheers ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 10/21] memblock: refactor internal allocation functions
Currently, memblock has several internal functions with overlapping
functionality. They all call memblock_find_in_range_node() to find free
memory and then reserve the allocated range and mark it with kmemleak.
However, there is difference in the allocation constraints and in fallback
strategies.
The allocations returning physical address first attempt to find free
memory on the specified node within mirrored memory regions, then retry on
the same node without the requirement for memory mirroring and finally fall
back to all available memory.
The allocations returning virtual address start with clamping the allowed
range to memblock.current_limit, attempt to allocate from the specified
node from regions with mirroring and with user defined minimal address. If
such allocation fails, next attempt is done with node restriction lifted.
Next, the allocation is retried with minimal address reset to zero and at
last without the requirement for mirrored regions.
Let's consolidate various fallbacks handling and make them more consistent
for physical and virtual variants. Most of the fallback handling is moved
to memblock_alloc_range_nid() and it now handles node and mirror fallbacks.
The memblock_alloc_internal() uses memblock_alloc_range_nid() to get a
physical address of the allocated range and converts it to virtual address.
The fallback for allocation below the specified minimal address remains in
memblock_alloc_internal() because memblock_alloc_range_nid() is used by CMA
with exact requirement for lower bounds.
The memblock_phys_alloc_nid() function is completely dropped as it is not
used anywhere outside memblock and its only usage can be replaced by a call
to memblock_alloc_range_nid().
Signed-off-by: Mike Rapoport
---
include/linux/memblock.h | 1 -
mm/memblock.c| 173 +--
2 files changed, 78 insertions(+), 96 deletions(-)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 6874fdc..cf4cd9c 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -371,7 +371,6 @@ static inline int memblock_get_region_node(const struct
memblock_region *r)
phys_addr_t memblock_phys_alloc_range(phys_addr_t size, phys_addr_t align,
phys_addr_t start, phys_addr_t end);
-phys_addr_t memblock_phys_alloc_nid(phys_addr_t size, phys_addr_t align, int
nid);
phys_addr_t memblock_phys_alloc_try_nid(phys_addr_t size, phys_addr_t align,
int nid);
static inline phys_addr_t memblock_phys_alloc(phys_addr_t size,
diff --git a/mm/memblock.c b/mm/memblock.c
index 531fa77..739f769 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1312,30 +1312,84 @@ __next_mem_pfn_range_in_zone(u64 *idx, struct zone
*zone,
#endif /* CONFIG_DEFERRED_STRUCT_PAGE_INIT */
+/**
+ * memblock_alloc_range_nid - allocate boot memory block
+ * @size: size of memory block to be allocated in bytes
+ * @align: alignment of the region and block's size
+ * @start: the lower bound of the memory region to allocate (phys address)
+ * @end: the upper bound of the memory region to allocate (phys address)
+ * @nid: nid of the free area to find, %NUMA_NO_NODE for any node
+ *
+ * The allocation is performed from memory region limited by
+ * memblock.current_limit if @max_addr == %MEMBLOCK_ALLOC_ACCESSIBLE.
+ *
+ * If the specified node can not hold the requested memory the
+ * allocation falls back to any node in the system
+ *
+ * For systems with memory mirroring, the allocation is attempted first
+ * from the regions with mirroring enabled and then retried from any
+ * memory region.
+ *
+ * In addition, function sets the min_count to 0 using kmemleak_alloc_phys for
+ * allocated boot memory block, so that it is never reported as leaks.
+ *
+ * Return:
+ * Physical address of allocated memory block on success, %0 on failure.
+ */
static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size,
phys_addr_t align, phys_addr_t start,
- phys_addr_t end, int nid,
- enum memblock_flags flags)
+ phys_addr_t end, int nid)
{
+ enum memblock_flags flags = choose_memblock_flags();
phys_addr_t found;
+ if (WARN_ONCE(nid == MAX_NUMNODES, "Usage of MAX_NUMNODES is
deprecated. Use NUMA_NO_NODE instead\n"))
+ nid = NUMA_NO_NODE;
+
if (!align) {
/* Can't use WARNs this early in boot on powerpc */
dump_stack();
align = SMP_CACHE_BYTES;
}
+ if (end > memblock.current_limit)
+ end = memblock.current_limit;
+
+again:
found = memblock_find_in_range_node(size, align, start, end, nid,
flags);
- if (found && !memblock_reserve(found, size)) {
+ if (found && !memblock_reserve(found, size))
+ goto do
