From: Tejun Heo <tj@kernel.org>
To: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org,
Yinghai Lu <yinghai@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Grygorii Strashko <grygorii.strashko@ti.com>
Subject: Re: [PATCH v2 08/23] mm/memblock: Add memblock memory allocation apis
Date: Tue, 3 Dec 2013 18:24:45 -0500 [thread overview]
Message-ID: <20131203232445.GX8277@htj.dyndns.org> (raw)
In-Reply-To: <1386037658-3161-9-git-send-email-santosh.shilimkar@ti.com>
Hello,
On Mon, Dec 02, 2013 at 09:27:23PM -0500, Santosh Shilimkar wrote:
> So we add equivalent APIs so that we can replace usage of bootmem
> with memblock interfaces. Architectures already converted to NO_BOOTMEM
> use these new interfaces and other which still uses bootmem, these new
> APIs just fallback to exiting bootmem APIs. So no functional change as
> such.
The last part of the second last sentence doesn't parse too well. I
think it'd be worthwhile to improve and preferably expand on it as
this is a bit tricky to understand given the twisted state of early
memory allocation.
> In long run, once all the achitectures moves to NO_BOOTMEM, we can get rid of
> bootmem layer completely. This is one step to remove the core code dependency
> with bootmem and also gives path for architectures to move away from bootmem.
Lines too long?
> +/*
> + * FIXME: use NUMA_NO_NODE instead of MAX_NUMNODES when bootmem/nobootmem code
> + * will be removed.
> + * It can't be done now, because when MEMBLOCK or NO_BOOTMEM are not enabled
> + * all calls of the new API will be redirected to bottmem/nobootmem where
> + * MAX_NUMNODES is widely used.
I don't know. We're introducing a new API which will be used across
the kernel. I don't think it makes a lot of sense to use the wrong
constant now to convert all the users later. Wouldn't it be better to
make the new interface take NUMA_NO_NODE and do whatever it needs to
do to interface with bootmem?
> + * Also, memblock core APIs __next_free_mem_range_rev() and
> + * __next_free_mem_range() would need to be updated, and as result we will
> + * need to re-check/update all direct calls of memblock_alloc_xxx()
> + * APIs (including nobootmem).
> + */
Hmmm....
> +/* FIXME: Move to memblock.h at a point where we remove nobootmem.c */
> +void *memblock_virt_alloc_try_nid_nopanic(phys_addr_t size,
> + phys_addr_t align, phys_addr_t from,
> + phys_addr_t max_addr, int nid);
Wouldn't @min_addr instead of @from make more sense? Ditto for other
occurrences.
> +void *memblock_virt_alloc_try_nid(phys_addr_t size, phys_addr_t align,
> + phys_addr_t from, phys_addr_t max_addr, int nid);
> +void __memblock_free_early(phys_addr_t base, phys_addr_t size);
> +void __memblock_free_late(phys_addr_t base, phys_addr_t size);
> +
> +#define memblock_virt_alloc(x) \
> + memblock_virt_alloc_try_nid(x, SMP_CACHE_BYTES, BOOTMEM_LOW_LIMIT, \
> + BOOTMEM_ALLOC_ACCESSIBLE, MAX_NUMNODES)
The underlying function interprets 0 as the default align, so it
probably is a better idea to just use 0 here.
> +#define memblock_virt_alloc_align(x, align) \
> + memblock_virt_alloc_try_nid(x, align, BOOTMEM_LOW_LIMIT, \
> + BOOTMEM_ALLOC_ACCESSIBLE, MAX_NUMNODES)
Also, do we really need this align variant separate when the caller
can simply specify 0 for the default?
> +#define memblock_virt_alloc_nopanic(x) \
> + memblock_virt_alloc_try_nid_nopanic(x, SMP_CACHE_BYTES, \
> + BOOTMEM_LOW_LIMIT, \
> + BOOTMEM_ALLOC_ACCESSIBLE, \
> + MAX_NUMNODES)
> +#define memblock_virt_alloc_align_nopanic(x, align) \
> + memblock_virt_alloc_try_nid_nopanic(x, align, \
> + BOOTMEM_LOW_LIMIT, \
> + BOOTMEM_ALLOC_ACCESSIBLE, \
> + MAX_NUMNODES)
> +#define memblock_virt_alloc_node(x, nid) \
> + memblock_virt_alloc_try_nid(x, SMP_CACHE_BYTES, BOOTMEM_LOW_LIMIT, \
> + BOOTMEM_ALLOC_ACCESSIBLE, nid)
> +#define memblock_virt_alloc_node_nopanic(x, nid) \
> + memblock_virt_alloc_try_nid_nopanic(x, SMP_CACHE_BYTES, \
> + BOOTMEM_LOW_LIMIT, \
> + BOOTMEM_ALLOC_ACCESSIBLE, nid)
> +
> +#define memblock_free_early(x, s) __memblock_free_early(x, s)
> +#define memblock_free_early_nid(x, s, nid) __memblock_free_early(x, s)
> +#define memblock_free_late(x, s) __memblock_free_late(x, s)
Please make the wrappers inline functions.
> +#else
> +
> +#define BOOTMEM_ALLOC_ACCESSIBLE 0
> +
> +
> +/* Fall back to all the existing bootmem APIs */
> +#define memblock_virt_alloc(x) \
> + __alloc_bootmem(x, SMP_CACHE_BYTES, BOOTMEM_LOW_LIMIT)
> +#define memblock_virt_alloc_align(x, align) \
> + __alloc_bootmem(x, align, BOOTMEM_LOW_LIMIT)
> +#define memblock_virt_alloc_nopanic(x) \
> + __alloc_bootmem_nopanic(x, SMP_CACHE_BYTES, BOOTMEM_LOW_LIMIT)
> +#define memblock_virt_alloc_align_nopanic(x, align) \
> + __alloc_bootmem_nopanic(x, align, BOOTMEM_LOW_LIMIT)
> +#define memblock_virt_alloc_node(x, nid) \
> + __alloc_bootmem_node(NODE_DATA(nid), x, SMP_CACHE_BYTES, \
> + BOOTMEM_LOW_LIMIT)
> +#define memblock_virt_alloc_node_nopanic(x, nid) \
> + __alloc_bootmem_node_nopanic(NODE_DATA(nid), x, SMP_CACHE_BYTES, \
> + BOOTMEM_LOW_LIMIT)
> +#define memblock_virt_alloc_try_nid(size, align, from, max_addr, nid) \
> + __alloc_bootmem_node_high(NODE_DATA(nid), size, align, from)
> +#define memblock_virt_alloc_try_nid_nopanic(size, align, from, max_addr, nid) \
> + ___alloc_bootmem_node_nopanic(NODE_DATA(nid), size, align, \
> + from, max_addr)
> +#define memblock_free_early(x, s) free_bootmem(x, s)
> +#define memblock_free_early_nid(x, s, nid) \
> + free_bootmem_node(NODE_DATA(nid), x, s)
> +#define memblock_free_late(x, s) free_bootmem_late(x, s)
> +
> +#endif /* defined(CONFIG_HAVE_MEMBLOCK) && defined(CONFIG_NO_BOOTMEM) */
Ditto.
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 1d15e07..3311fbb 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -21,6 +21,9 @@
> #include <linux/memblock.h>
>
> #include <asm-generic/sections.h>
> +#include <asm/io.h>
> +
> +#include "internal.h"
>
> static struct memblock_region memblock_memory_init_regions[INIT_MEMBLOCK_REGIONS] __initdata_memblock;
> static struct memblock_region memblock_reserved_init_regions[INIT_MEMBLOCK_REGIONS] __initdata_memblock;
> @@ -933,6 +936,198 @@ phys_addr_t __init memblock_alloc_try_nid(phys_addr_t size, phys_addr_t align, i
> return memblock_alloc_base(size, align, MEMBLOCK_ALLOC_ACCESSIBLE);
> }
>
> +/**
> + * _memblock_virt_alloc_try_nid_nopanic - allocate boot memory block
Please don't use both "__" and "_" prefixes. It gets confusing like
hell. Just give it an another name.
> + * @size: size of memory block to be allocated in bytes
> + * @align: alignment of the region and block's size
> + * @from: the lower bound of the memory region from where the allocation
> + * is preferred (phys address)
> + * @max_addr: the upper bound of the memory region from where the allocation
> + * is preferred (phys address), or %BOOTMEM_ALLOC_ACCESSIBLE to
> + * allocate only from memory limited by memblock.current_limit value
It probably would be better style to make the above shorter and fit
each on a single line. If they need further explanation, they can be
done in the body of the comment.
> + * @nid: nid of the free area to find, %MAX_NUMNODES for any node
> + *
> + * The @from limit is dropped if it can not be satisfied and the allocation
> + * will fall back to memory below @from.
> + *
> + * Allocation may fall back to any node in the system if the specified node
> + * can not hold the requested memory.
Maybe combine the above two paragraphs?
> + * The phys address of allocated boot memory block is converted to virtual and
> + * allocated memory is reset to 0.
> + *
> + * In addition, function sets sets the min_count for allocated boot memory block
^^^^^^^^^
No mention of kmemleak at all is a bit confusing. min_count of what?
> + * to 0 so that it is never reported as leaks.
> + *
> + * RETURNS:
> + * Virtual address of allocated memory block on success, NULL on failure.
> + */
> +static void * __init _memblock_virt_alloc_try_nid_nopanic(
> + phys_addr_t size, phys_addr_t align,
> + phys_addr_t from, phys_addr_t max_addr,
> + int nid)
> +{
> + phys_addr_t alloc;
> + void *ptr;
> +
> + if (WARN_ON_ONCE(slab_is_available())) {
> + if (nid == MAX_NUMNODES)
> + return kzalloc(size, GFP_NOWAIT);
> + else
> + return kzalloc_node(size, GFP_NOWAIT, nid);
> + }
> +
> + if (!align)
> + align = SMP_CACHE_BYTES;
> +
> + /* align @size to avoid excessive fragmentation on reserved array */
> + size = round_up(size, align);
> +
> +again:
> + alloc = memblock_find_in_range_node(from, max_addr, size, align, nid);
Not your fault but we probably wanna update these functions so that
their param orders are consistent.
Thanks.
--
tejun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2013-12-03 23:24 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-03 2:27 [PATCH v2 00/23] mm: Use memblock interface instead of bootmem Santosh Shilimkar
2013-12-03 2:27 ` [PATCH v2 01/23] mm/memblock: debug: correct displaying of upper memory boundary Santosh Shilimkar
2013-12-03 2:27 ` [PATCH v2 02/23] mm/memblock: debug: don't free reserved array if !ARCH_DISCARD_MEMBLOCK Santosh Shilimkar
2013-12-03 22:52 ` Tejun Heo
2013-12-04 14:58 ` Santosh Shilimkar
2013-12-03 2:27 ` [PATCH v2 03/23] mm/bootmem: remove duplicated declaration of __free_pages_bootmem() Santosh Shilimkar
2013-12-03 22:53 ` Tejun Heo
2013-12-03 2:27 ` [PATCH v2 04/23] mm/memory_hotplug: remove unnecessary inclusion of bootmem.h Santosh Shilimkar
2013-12-03 22:54 ` Tejun Heo
2013-12-03 2:27 ` [PATCH v2 05/23] mm/staging: " Santosh Shilimkar
2013-12-03 2:27 ` [PATCH v2 06/23] mm/char: " Santosh Shilimkar
2013-12-03 22:55 ` Tejun Heo
2013-12-04 14:57 ` Santosh Shilimkar
2013-12-03 2:27 ` [PATCH v2 07/23] mm/memblock: drop WARN and use SMP_CACHE_BYTES as a default alignment Santosh Shilimkar
2013-12-03 22:58 ` Tejun Heo
2013-12-03 2:27 ` [PATCH v2 08/23] mm/memblock: Add memblock memory allocation apis Santosh Shilimkar
2013-12-03 23:24 ` Tejun Heo [this message]
2013-12-04 15:54 ` Santosh Shilimkar
2013-12-04 16:07 ` Tejun Heo
2013-12-04 16:46 ` Santosh Shilimkar
2013-12-05 13:12 ` Grygorii Strashko
2013-12-05 16:59 ` Tejun Heo
2013-12-05 17:13 ` Santosh Shilimkar
2014-01-11 0:53 ` Andrew Morton
2014-01-11 0:59 ` Santosh Shilimkar
2013-12-05 16:35 ` Grygorii Strashko
2013-12-05 16:53 ` Tejun Heo
2013-12-05 18:48 ` Strashko, Grygorii
2013-12-05 18:51 ` Tejun Heo
2013-12-05 20:34 ` Santosh Shilimkar
2013-12-06 14:52 ` Grygorii Strashko
2013-12-03 2:27 ` [PATCH v2 09/23] mm/init: Use memblock apis for early memory allocations Santosh Shilimkar
2013-12-03 2:27 ` [PATCH v2 10/23] mm/printk: " Santosh Shilimkar
2013-12-03 2:27 ` [PATCH v2 11/23] mm/page_alloc: " Santosh Shilimkar
2013-12-03 2:27 ` [PATCH v2 12/23] mm/power: " Santosh Shilimkar
2013-12-03 2:27 ` [PATCH v2 13/23] mm/lib/swiotlb: " Santosh Shilimkar
2013-12-03 2:27 ` [PATCH v2 14/23] mm/lib/cpumask: " Santosh Shilimkar
2013-12-03 2:27 ` [PATCH v2 15/23] mm/sparse: " Santosh Shilimkar
2013-12-03 2:27 ` [PATCH v2 16/23] mm/hugetlb: " Santosh Shilimkar
2013-12-03 2:27 ` [PATCH v2 17/23] mm/page_cgroup: " Santosh Shilimkar
2013-12-03 2:27 ` [PATCH v2 18/23] mm/percpu: " Santosh Shilimkar
2013-12-03 2:27 ` [PATCH v2 19/23] mm/memory_hotplug: " Santosh Shilimkar
2013-12-03 2:27 ` [PATCH v2 20/23] mm/firmware: " Santosh Shilimkar
2013-12-03 2:27 ` [PATCH v2 21/23] mm/ARM: kernel: " Santosh Shilimkar
2013-12-03 2:27 ` [PATCH v2 22/23] mm/ARM: mm: " Santosh Shilimkar
2013-12-03 2:27 ` [PATCH v2 23/23] mm/ARM: OMAP: " Santosh Shilimkar
2013-12-03 22:48 ` [PATCH v2 00/23] mm: Use memblock interface instead of bootmem Tejun Heo
2013-12-04 14:56 ` Santosh Shilimkar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131203232445.GX8277@htj.dyndns.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=grygorii.strashko@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=santosh.shilimkar@ti.com \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).